Benutzer mit den meisten Antworten
Letzte aufrufende, übergeordnete Codestelle ermitteln

Frage
-
Grüße
Ich hab hier ein kleines Problem. Folgender Code gibt wieder meinen Erwartungen nicht den kompletten letzten Stacktrace in der RichTextBox aus.
public partial class Form1 : Form { private static class Abc { public static string Run() { return Def.Run(); } } private static class Def { public static string Run() { // In der Methode möchte ich die aufrufende Quelle wissen return Environment.StackTrace; } } public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { richTextBox1.Text = Abc.Run(); } }
Eigentlich sollte da im Output eigentlich noch ein Hinweis auf Abc.Run() enthalten sein. Aber ich bekomme nur folgenden Output:
bei System.Environment.GetStackTrace(Exception e, Boolean needFileInfo) bei System.Environment.get_StackTrace() bei WindowsFormsApplication1.Form1.Def.Run() bei WindowsFormsApplication1.Form1.Form1_Load(Object sender, EventArgs e) …
Ich muß dazu sagen das das nur dann der Fall ist wenn die zu WindowsFormsApplication1.exe gehörende WindowsFormsApplication1.pdb nicht im Verzeichnis der Anwendung liegt
Da ich nicht weis ob Libraries, die Meine Lib einbinden (Code oben ist nur zum Probieren) ihre *.pdb-Datei definieren bin ich gerade ein bischen ratlos, wie ich dann später mal in meiner eigenen Library z.B. in einer Methode erfahren kann in welcher Klasse+Methode diese meine Librarymethode aufgerufen wurde.
Sinn hinter dem Ganzen ist, das ich mir gerade mal zum Anlernen einen eigenen Loger schreiben will. Wenn z.B. Log.Debug(string message) in einer einbindenden Anwendung aufgerufen wird will ich nicht erst zwingend über einen Extra-Parameter angeben müssen Von wo aus Log.Debug(…) aufgerufen wurde.
Hab jemand eine Idde für mich?
Gruß, Roman
Antworten
-
Hallo Roman,
zum einen ist das natürlich so gedacht, dass die Zeilen in Releases nicht sichtbar sein sollen, denn dort sind ggf. Informationen (->Sicherheit), die nicht für den Kunden gedacht sind und die er sonst in einer Ausnahme sehen könnte. Der Weg, die PDBs einzuspielen ist dafür einer der Vorgesehenen.Jedoch sollte man - wenn man an die Optimierung denkt - möglichst nicht die gesamte Optimierung ausschalten (müssen). Dann würde das Programm ggf. langsam werden. Man kann hier aber auch mit Attributen arbeiten, um nur bestimmte Teile nicht optimieren zu lassen. Das könnte man zum Beispiel so machen, indem man ein
[MethodImpl(MethodImplOptions.NoOptimization)]
vor die gewünschte Methode schreibt:
[MethodImplOptions-Enumeration (System.Runtime.CompilerServices)]
[MethodImplAttribute-Klasse (System.Runtime.CompilerServices)]
Der globale Schalter: [/optimize (C#-Compileroptionen)] oder das Nicht-Abhaken der "Code optimieren" -Checkbox unter den Projekt/Erstellen-Optionen ist eher die brutale Methode, aber natürlich auch möglich.
ciao Frank- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 8. März 2011 17:02
-
Langfristig hast du keine Chance. Spätestens im Release wirst du ja Deinen Code optimieren lassen. Der Optimizer entfernt jede kleine funktion, die nicht viel Inhalt hat. Bei mir im Release wurde sogar noch Def.Run() wegoptimiert.
Du kannst natürlich den Optimizer ausschalten....
- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 8. März 2011 17:02
Alle Antworten
-
Langfristig hast du keine Chance. Spätestens im Release wirst du ja Deinen Code optimieren lassen. Der Optimizer entfernt jede kleine funktion, die nicht viel Inhalt hat. Bei mir im Release wurde sogar noch Def.Run() wegoptimiert.
Du kannst natürlich den Optimizer ausschalten....
- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 8. März 2011 17:02
-
Hallo Roman,
zum einen ist das natürlich so gedacht, dass die Zeilen in Releases nicht sichtbar sein sollen, denn dort sind ggf. Informationen (->Sicherheit), die nicht für den Kunden gedacht sind und die er sonst in einer Ausnahme sehen könnte. Der Weg, die PDBs einzuspielen ist dafür einer der Vorgesehenen.Jedoch sollte man - wenn man an die Optimierung denkt - möglichst nicht die gesamte Optimierung ausschalten (müssen). Dann würde das Programm ggf. langsam werden. Man kann hier aber auch mit Attributen arbeiten, um nur bestimmte Teile nicht optimieren zu lassen. Das könnte man zum Beispiel so machen, indem man ein
[MethodImpl(MethodImplOptions.NoOptimization)]
vor die gewünschte Methode schreibt:
[MethodImplOptions-Enumeration (System.Runtime.CompilerServices)]
[MethodImplAttribute-Klasse (System.Runtime.CompilerServices)]
Der globale Schalter: [/optimize (C#-Compileroptionen)] oder das Nicht-Abhaken der "Code optimieren" -Checkbox unter den Projekt/Erstellen-Optionen ist eher die brutale Methode, aber natürlich auch möglich.
ciao Frank- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 8. März 2011 17:02