【发布时间】:2010-09-07 16:43:22
【问题描述】:
我应该在什么时候为生产版本包含 PDB 文件?我应该使用Optimize code 标志吗?这将如何影响我从异常中获得的信息?
如果有明显的性能优势,我想使用优化,但如果没有,我宁愿获得准确的调试信息。生产应用程序通常会做什么?
【问题讨论】:
标签: c# visual-studio build-process
我应该在什么时候为生产版本包含 PDB 文件?我应该使用Optimize code 标志吗?这将如何影响我从异常中获得的信息?
如果有明显的性能优势,我想使用优化,但如果没有,我宁愿获得准确的调试信息。生产应用程序通常会做什么?
【问题讨论】:
标签: c# visual-studio build-process
如果您想在堆栈跟踪中查看源文件名和行号,请使用 pdb-only 选项生成 PDB。优化与 PDB 生成是分开的,即您可以优化和生成 PDB 而不会影响性能。
如果您使用 /debug:full,请注意,使用 /debug:full 会对 JIT 优化代码的速度和大小产生一些影响,而对代码质量的影响很小。我们建议使用 /debug:pdbonly 或不使用 PDB 来生成发布代码。
【讨论】:
要回答您的第一个问题,如果您需要异常报告的行号,则只需包含生产版本的 PDB。
要回答您的第二个问题,对 PDB 使用“优化”标志意味着任何 stack "collapse" will be reflected in the stack trace.我不确定报告的实际行号是否有误 - 这需要更多调查。
要回答您的第三个问题,您可以通过一个相当巧妙的技巧来两全其美。默认调试构建和默认发布构建之间的主要区别在于,在执行默认发布构建时,优化被打开并且不发出调试符号。所以,分四步:
更改您的发布配置以发出调试符号。这对您的应用程序的性能几乎没有影响,如果(何时?)您需要调试应用程序的发布版本,这将非常有用。
使用您的新版本构建配置进行编译,即 with 调试符号和 with 优化。请注意,99% 的代码优化是由 JIT 编译器完成的,而不是语言编译器。
在应用的文件夹中创建一个名为 xxxx.exe.ini(或 dll 或其他)的文本文件,其中 xxxx 是可执行文件的名称。此文本文件最初应如下所示:
[.NET Framework Debugging Control]
GenerateTrackingInfo=0
AllowOptimize=1
通过这些设置,您的应用可以全速运行。当您想通过打开调试跟踪并可能关闭 (CIL) 代码优化来调试您的应用程序时,只需使用以下设置:
[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0
EDIT根据cateye的评论,this can also work in a hosted environment如ASP.NET。
【讨论】:
没有必要将它们包含在您的发行版中,但您绝对应该构建并保留它们。否则调试故障转储几乎是不可能的。
我也会开启优化。虽然它确实使调试更加困难,但性能提升通常非常重要,具体取决于应用程序的性质。对于某些算法,我们很容易看到发布版本与调试版本的性能提高了 10 倍以上。
【讨论】: