生产应用程序的 PDB 文件和“优化代码”标志

Posted 2023-04-12

【中文标题】生产应用程序的 PDB 文件和“优化代码”标志

【英文标题】：PDB files for production app and the "Optimize code" flag

【发布时间】：2010-09-07 16:43:22

【问题描述】：

我应该在什么时候为生产版本包含 PDB 文件？我应该使用Optimize code 标志吗？这将如何影响我从异常中获得的信息？

如果有明显的性能优势，我想使用优化，但如果没有，我宁愿获得准确的调试信息。生产应用程序通常会做什么？

【问题讨论】：

查看blog.vuscode.com/malovicn/archive/2007/08/05/…中的选项比较

【参考方案1】：

如果您想在堆栈跟踪中查看源文件名和行号，请​​使用 pdb-only 选项生成 PDB。优化与 PDB 生成是分开的，即您可以优化和生成 PDB 而不会影响性能。

来自the C# Language Reference

如果您使用 /debug:full，请注意，使用 /debug:full 会对 JIT 优化代码的速度和大小产生一些影响，而对代码质量的影响很小。我们建议使用 /debug:pdbonly 或不使用 PDB 来生成发布代码。

【参考方案2】：

要回答您的第一个问题，如果您需要异常报告的行号，则只需包含生产版本的 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。

【讨论】：

>要回答您的第二个问题，将“优化”标志与 PDB 一起使用 >意味着这些行号可能会偏离几行。你确定这是真的吗？

不，我不确定。我已经更正了我的答案以反映我确信的差异（堆栈崩溃）。我需要更详细地研究线差理论。

您应该注明您的来源 - Scott Hanselman hanselman.com/blog/DebugVsReleaseTheBestOfBothWorlds.aspx

@Cristi，Scott 博客条目的来源是一个叫 Mark Pearce 的人。那是我:-)

这篇 ASP.NET MVC SOURCE DEBUGGING THE EASY WAY 可以为我的上述问题提供线索，即只需将 .ini 文件放入 dll 所在的 asp.net 临时文件夹中即可。

【参考方案3】：

没有必要将它们包含在您的发行版中，但您绝对应该构建并保留它们。否则调试故障转储几乎是不可能的。

我也会开启优化。虽然它确实使调试更加困难，但性能提升通常非常重要，具体取决于应用程序的性质。对于某些算法，我们很容易看到发布版本与调试版本的性能提高了 10 倍以上。

【讨论】：

将 PDB 复制到生产环境中是个好主意（至少对于网站而言）。请参阅***.com/questions/933883/… BTW，如果您在部署中包含 PDB，则无需将它们保存在符号服务器等单独的地方