不要在堆栈跟踪中显示构建机器的文件路径
我目前正在开发一个 C# 应用程序，它有自己的日志记录。当抛出异常时，异常被保存到一个列表中，用户可以通过列表视图查看该列表。 当用户单击列表视图中的异常时，该异常的堆栈跟踪将显示在文本框中。但即使当我在远程计算机上执行程序时，堆栈跟踪也会显示从编译应用程序的计算机到原始源文件的文件路径。
例如：
at C:\Folder1\Folder2\Class1.cs:81
at C:\Folder1\Folder2\Class2.cs:65
at C:\Folder1\Folder1\Class3.cs:21
只显示没有文件夹的源文件就好了...
我怎样才能改变这种行为？
有没有原生解决方案？或者我必须简单地进行一些字符串操作？
I am currently developing a C# application which has got it's own logging. When exceptions are thrown, the exception is saved into a list which can be viewed by the user via a list view.
When the user clicks on a exception in the list view, the stack trace of the exception is shown in a text box. But even when I am executing the program on a remote machine, the stack trace shows the file paths to the original source files from the machine where the application was compiled.
e.g.:
at C:\Folder1\Folder2\Class1.cs:81
at C:\Folder1\Folder2\Class2.cs:65
at C:\Folder1\Folder1\Class3.cs:21
Only displaying the source files without folders would be nice...
How can I change this behaviour?
Is there any native solution? Or do I have to simply do some string manipulation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能拥有已安装应用程序的 .pdb 文件。如果没有 .pdb 文件，它不应显示文件位置。
查看 获取异常堆栈跟踪中的行号在Windows服务中
和在堆栈跟踪中包含行号，而不pdb？
You probably have the .pdb files with the installed app. Without the .pdb files, it should not show the file locations.
Have a look at Getting line numbers in exception stack trace in a Windows Service
and include line numbers in stack trace without pdb?
文件路径包含在“程序数据库”文件 (.pdb) 中。此类文件是在编译期间创建的，这些文件中的路径与编译机器上的路径相同。
您可以从安装中删除 .pdb 文件，但这样您的堆栈跟踪将只有现在的一半，因为它不会告诉您发生错误的行。通常，您不会在附加 Pdb 文件的生产环境中运行代码。
如果您想保留“有趣的堆栈跟踪”，可以考虑在调用
exceptionObject.toString()后对文件夹名称进行字符串替换。The file paths are included in "program database" files (.pdb). Such files are created during compilation and paths in these files are as on the compilation machine.
You can remove the .pdb files from your installation, but this way your stack trace will be just half as interesting as it is now, since it will not tell you the line on which the error happened. Normally, you don't run code in production environment with Pdb files attached.
If you want to keep the "interesting stack trace", you can consider doing a string replacement of folder names, after you have called
exceptionObject.toString().