我应该将调试信息编译为“完整”还是“仅 pdb”吗？

Question

在 Visual Studio for C# 项目中，如果转到项目属性 > 生成 > 高级 > 调试信息，您有三个选项：

none

、

full

或

pdb-only

。

哪种设置最适合发布版本？

---

那么，

full

和

pdb-only

有什么区别？

如果我使用

full

会对性能产生影响吗？如果我使用

pdb-only

调试生产问题会更困难吗？

Answer 1

我会用

pdb-only

来构建。您将无法将调试器附加到已发布的产品，但如果您获得崩溃转储，您可以使用 Visual Studio 或 WinDBG 检查崩溃时的堆栈跟踪和内存转储。

如果您使用

full

而不是

pdb-only

，您将获得相同的好处，只不过可执行文件可以直接附加到调试器。您需要根据您的产品和客户确定这是否合理。

请务必将 PDB 文件保存在某个地方，以便在收到崩溃报告时可以引用它们。如果您可以设置一个 符号服务器 来存储这些调试符号，那就更好了。

如果您选择使用

none

进行构建，那么当现场发生事故时您将无法追索。您将无法对事故进行任何形式的事后检查，这可能会严重妨碍您追踪问题的能力。

关于性能的说明：

John Robbins 和Eric Lippert 都撰写了有关

/debug

标志的博客文章，他们都表示此设置对性能有零影响。有一个单独的 /optimize

 标志指示编译器是否应该执行优化。

Answer 2

警告 /debug 开关的 MSDN documentation（在 Visual Studio 中是调试信息）似乎已经过时了！这就是它的内容，但不正确

如果您使用 /debug:

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

/debug:

pdbonly 和 /debug:full 之间的一个区别是 /debug:full 编译器发出一个 DebuggableAttribute

，用于
  告诉 JIT 编译器调试信息可用。

那么，现在的情况是怎样的呢？

1. 仅 Pdb – 在 .NET 2.0 之前，它有助于调查已发布产品（客户计算机）的故障转储。但它不允许附加调试器。 .NET 2.0 中的情况并非如此。它完全与完整相同。
2. Full – 这有助于我们调查故障转储，还允许我们附加调试器来发布版本。但与 MSDN 提到的不同，它不会影响性能（自 .NET 2.0 起）。它的作用与Pdb-only完全相同。

如果它们完全相同，为什么我们有这些选项？ John Robbins（Windows调试大神）

发现这些都是有历史原因的。

在 .NET 1.0 中存在差异，但在 .NET 2.0 中则没有。 看起来 .NET 4.0 将遵循相同的模式。后 与 CLR 调试团队仔细检查，没有任何区别 全部。

控制 JITter 是否进行调试构建的是 /optimize 转变。

<…>

底线是你想用以下方式构建你的发布版本 /optimize+ 和任何 /debug 开关，以便您可以使用源代码进行调试 代码。

然后他继续证明这一点。

现在优化是单独开关的一部分

/optimize

（在 Visual Studio 中称为 

Optimize code

）。

简而言之，无论 DebugInfo 设置 pdb-only 还是 full，我们都会得到相同的结果。建议避免

无，因为它会剥夺您分析已发布产品或附加调试器的故障转储的能力。

Answer 3

您只需要 PDB，但您不想将 PDB 文件提供给用户。不过，将它们与二进制文件一起使用，可以让您将故障转储加载到 WinDbg 等调试器中，并查看程序实际失败的位置。当您的代码在您无权访问的计算机上崩溃时，这可能非常有用。

完全调试将 [Debuggable] 属性添加到您的代码中。这对速度有很大影响。例如，可以禁用某些循环优化以使单步执行更容易。此外，它对 JIT 流程的影响很小，因为它打开了跟踪。

Answer 4

我正在编写未处理的异常处理程序，并且堆栈跟踪包括使用 pdb-only 时的行号，否则当我选择“无”时，我只会获取子/函数的名称。

如果我不分发 .pdb，即使使用仅 pdb 构建，我也不会在堆栈跟踪中获得行号。

因此，我将 pdb 与 VB 应用程序中的 exe 一起分发（XCOPY 部署在 LAN 上）。