Dateipfade der Erstellungsmaschine im Stack-Trace nicht anzeigen

Question

Ich entwickle gerade eine C# -Anwendung, die über eine eigene Protokollierung verfügt. Wenn Ausnahmen ausgelöst werden, wird die Ausnahme in einer Liste gespeichert, die vom Benutzer über eine Listenansicht angezeigt werden kann. Wenn der Benutzer auf eine Ausnahme in der Listenansicht klickt, wird die Stapelverfolgung der Ausnahme in einem Textfeld angezeigt. Aber selbst wenn ich das Programm auf einem Remote-Computer ausführe, zeigt der Stack-Trace die Dateipfade zu den ursprünglichen Quelldateien von der Maschine, auf der die Anwendung kompiliert wurde.

z.B .:

at C:\Folder1\Folder2\Class1.cs:81 
at C:\Folder1\Folder2\Class2.cs:65 
at C:\Folder1\Folder1\Class3.cs:21 

Anzeigen Nur die Quelldateien ohne Ordner wäre schön ...

Wie kann ich dieses Verhalten zu ändern?

Gibt es eine native Lösung? Oder muss ich einfach eine String-Manipulation machen?

Answer 1

Sie haben wahrscheinlich die PDB-Dateien mit der installierten App. Ohne die PDB-Dateien sollten die Dateispeicherorte nicht angezeigt werden.

Werfen Sie einen Blick auf Getting line numbers in exception stack trace in a Windows Service

und include line numbers in stack trace without pdb?

Sie nicht einen Stack-Trace mit Linie Nummern direkt aus Ihrer Anwendung , wenn Sie die PDB bündeln bekommen können.

Answer 2

Die Dateipfade sind in den Dateien "program database" (.pdb) enthalten. Solche Dateien werden während der Kompilierung erstellt, und die Pfade in diesen Dateien entsprechen denen auf dem Kompilierungscomputer.

Sie können die .pdb-Dateien aus Ihrer Installation entfernen, aber auf diese Weise ist Ihr Stack-Trace nur halb so interessant wie jetzt, da er Ihnen nicht die Zeile angibt, in der der Fehler aufgetreten ist. Normalerweise wird Code in der Produktionsumgebung nicht mit angehängten Pdb-Dateien ausgeführt.

Wenn Sie den "interessanten Stack-Trace" beibehalten möchten, können Sie einen String-Ersatz von Ordnernamen in Erwägung ziehen, nachdem Sie exceptionObject.toString() aufgerufen haben.