我是否应该将debugging信息编译为“完整”或“仅限pdb”？
在用于C＃项目的Visual Studio 2010中，如果转到“项目属性”>“生成”>“高级”>“debugging信息”，则有三个选项：none，full或pdb-only。 基于这个问题的答案，我相信我理解了完全和pdb-only之间的一些区别。 但是，哪个更适合发布版本？ 如果我使用“全部”，会有性能方面的影响吗？ 如果我使用“仅限pdb”，将难以debugging生产问题？
我会build立与pdb-only 。 您将无法将debugging器附加到发布的产品，但是如果您收到故障转储，则可以使用Visual Studio或WinDBG在崩溃时检查堆栈跟踪和内存转储。
如果使用full而不是pdb-only ，那么除了可执行文件可以直接连接到debugging器之外，您将获得相同的好处。 您需要确定您的产品和客户是否合理。
请务必将PDB文件保存在某处，以便在出现崩溃报告时引用它们。如果可以设置符号服务器来存储这些debugging符号，那就更好了。
如果你selectnonebuild设的话，那么在现场发生崩溃的时候你就没有办法了。 您将无法对事故进行任何forms的事后检查，这可能会严重妨碍您追踪问题的能力。
关于performance的说明：
John Robbins和Eric Lippert都写了关于/debug标志的博客文章，他们都表示这个设置对性能没有影响 。 有一个单独/optimize标志，指示编译器是否应执行优化。
警告 /debugging开关MSDN 文档 （在Visual Studio中它是debugging信息）似乎是过时的！ 这是它有什么不正确的
如果您使用/ debug： full ，请注意，对JIT优化代码的速度和大小会有一些影响，而对/ debug： full则会影响代码质量。 我们build议/debugging： pdbonly或没有PDB用于生成发行代码。
/ debug： pdbonly和/ debug： full之间的一个区别在于/ debug：full时，编译器会发出一个
DebuggableAttribute，用于告诉JIT编译器debugging信息可用。
那么，现在是什么？
- Pdb-only在.NET 2.0之前，它帮助调查了发布产品（客户机器）的崩溃转储。 但它没有让附加debugging器。 .NET 2.0并不是这种情况。 它和Full 完全一样。
- 完整 – 这有助于我们调查崩溃转储，并允许我们附加debugging器来发布构build。 但是不像MSDN提到的那样，它不会影响性能（从.NET 2.0开始）。 它和Pdb-only完全一样。
如果他们完全一样，为什么我们有这些select？ 约翰·罗宾斯（窗户debugging神） 发现这些是由于历史原因。
在.NET 1.0中有差异，但是在.NET 2.0中没有。 它看起来像.NET 4.0将遵循相同的模式。 经过与CLRdebugging团队的双重检查后，没有任何区别。
什么控制JITter是否进行debugging构build是/ optimize开关。 <…>
底线是你想用/ optimize +和任何的/ debug开关构build你的发行版本，这样你就可以用源代码进行debugging。
然后他继续certificate这一点。
现在优化是一个单独的开关/optimize （在Visual Studio中称为Optimize code ）的一部分。
总之，不pipeDebugInfo设置pdb-only还是full，我们都会得到相同的结果。 build议避免使用None，因为这会使您无法分析已发布产品的崩溃转储或附加debugging器。
你只需要PDB，但是你不想把PDB文件给用户。 尽pipe如此，除了二进制文件之外，还可以将崩溃转储加载到像WinDbg这样的debugging器中，并查看程序实际失败的位置。 当你的代码在没有权限访问的机器上崩溃时，这可能会非常有用。
完整的debugging将[Debuggable]属性添加到您的代码中。 这对速度有很大的影响。 例如，可能会禁用某些循环优化，使单步更容易。 另外，它对JIT过程的影响很小，因为它开始追踪。
我正在编写一个未处理的exception处理程序，并且当使用pdb-only时，堆栈跟踪包括行号，否则当我select无时，我只是获取子/函数的名称。
如果我不分发.pdb，那么即使只使用pdb构build，我也不会在堆栈跟踪中获得行号。
所以，我分配（XCOPY部署在局域网）的PDB与我的VB应用程序的EXE。
