visual-studio 生产应用程序的 PDB 文件和“优化代码”标志
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/41842/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
PDB files for production app and the "Optimize code" flag
提问by JC.
When should I include PDB files for a production release? Should I use the Optimize codeflag and how would that affect the information I get from an exception?
我应该什么时候为生产版本包含 PDB 文件？我是否应该使用该Optimize code标志以及这将如何影响我从异常中获得的信息？
If there is a noticeable performance benefit I would want to use the optimizations but if not I'd rather have accurate debugging info. What is typically done for a production app?
如果有明显的性能优势，我想使用优化，但如果没有，我宁愿拥有准确的调试信息。生产应用程序通常会做什么？
回答by Duncan Smart
When you want to see source filenames and line numbers in your stacktraces, generate PDBs using the pdb-only option. Optimization is separate from PDB generation, i.e. you can optimize andgenerate PDBs without a performance hit.
如果您想在堆栈跟踪中查看源文件名和行号，请使用 pdb-only 选项生成 PDB。优化与 PDB 生成是分开的，即您可以在不影响性能的情况下优化和生成 PDB。
From the C# Language Reference
来自C# 语言参考
If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.
如果您使用 /debug:full，请注意对 JIT 优化代码的速度和大小有一些影响，而使用 /debug:full 对代码质量的影响很小。我们建议使用 /debug:pdbonly 或 no PDB 来生成发布代码。
回答by HTTP 410
To answer your first question, you only need to include PDBs for a production release if you need line numbers for your exception reports.
要回答您的第一个问题，如果您的异常报告需要行号，您只需要包含生产版本的 PDB。
To answer your second question, using the "Optimise" flag with PDBs means that any stack "collapse" will be reflected in the stack trace. I'm not sure whether the actual line number reported can be wrong - this needs more investigation.
要回答您的第二个问题，对 PDB 使用“优化”标志意味着任何堆栈“崩溃”都将反映在堆栈跟踪中。我不确定报告的实际行号是否有误 - 这需要更多调查。
To answer your third question, you can have the best of both worlds with a rather neat trick. The major differences between the default debug build and default release build are that when doing a default release build, optimization is turned on and debug symbols are not emitted. So, in four steps:
要回答你的第三个问题，你可以用一个相当巧妙的技巧来两全其美。默认调试构建和默认发布构建之间的主要区别在于，在执行默认发布构建时，优化被打开并且不发出调试符号。所以，分四步：
Change your release config to emit debug symbols. This has virtually no effect on the performance of your app, and is very useful if (when?) you need to debug a release build of your app.
Compile using your new release build config, i.e. withdebug symbols and withoptimization. Note that 99% of code optimization is done by the JIT compiler, not the language compiler.
Create a text file in your app's folder called xxxx.exe.ini (or dll or whatever), where xxxx is the name of your executable. This text file should initially look like:
[.NET Framework Debugging Control] GenerateTrackingInfo=0 AllowOptimize=1With these settings, your app runs at full speed. When you want to debug your app by turning on debug tracking and possibly turning off (CIL) code optimization, just use the following settings:
[.NET Framework Debugging Control] GenerateTrackingInfo=1 AllowOptimize=0
更改您的发布配置以发出调试符号。这对您的应用程序的性能几乎没有影响，并且在（何时？）您需要调试应用程序的发布版本时非常有用。
编译使用新的发布版本的配置，即与调试符号，并与优化。请注意，99% 的代码优化是由 JIT 编译器完成的，而不是语言编译器。
在您的应用程序文件夹中创建一个名为 xxxx.exe.ini（或 dll 或其他）的文本文件，其中 xxxx 是您的可执行文件的名称。此文本文件最初应如下所示：
[.NET Framework Debugging Control] GenerateTrackingInfo=0 AllowOptimize=1通过这些设置，您的应用程序可以全速运行。当您想通过打开调试跟踪并可能关闭 (CIL) 代码优化来调试您的应用程序时，只需使用以下设置：
[.NET Framework Debugging Control] GenerateTrackingInfo=1 AllowOptimize=0
EDITAccording to cateye's comment, this can also work in a hosted environmentsuch as ASP.NET.
回答by Rob Walker
There is no need to include them in your distribution, but you should definitely be building them and keeping them. Otherwise debugging a crash dump is practically impossible.
无需将它们包含在您的发行版中，但您绝对应该构建并保留它们。否则调试故障转储实际上是不可能的。
I would also turn on optimizations. Whilst it does make debugging more difficult the performance gains are usually very non-trivial depending on the nature of the application. We easily see over 10x performance on release vs debug builds for some algorithms.
我也会打开优化。虽然它确实使调试变得更加困难，但取决于应用程序的性质，性能提升通常非常重要。我们很容易看到某些算法的发布版本与调试版本的性能提高了 10 倍以上。
