我会用pdb-only来构建。您将无法将调试器附加到已发布的产品，但如果您获得崩溃转储，则可以使用Visual Studio或WinDBG检查崩溃时的堆栈跟踪和内存转储。
如果使用full而不是pdb-only，您将获得相同的好处，除了可执行文件可以直接附加到调试器。你需要确定这是否是合理的给定您的产品和客户.
请确保将PDB文件保存在某个位置，以便在出现崩溃报告时可以引用它们。如果您可以设置一个symbol server来存储这些调试符号，那就更好了。
如果您选择使用none构建，那么当在现场发生崩溃时，您将没有追索权。您将无法对崩溃进行任何形式的事后检查，这可能会严重妨碍您跟踪问题的能力。

性能说明：

John Robbins和Eric Lippert都写过关于/debug标志的博客文章，他们都表示此设置对性能的影响为 * 零。有一个单独的/optimize标志，指示编译器是否应该执行优化。

错误MSDN documentation for /debug开关（在Visual Studio中为“调试信息”）似乎已过期！这就是它所拥有的，这是不正确的。

如果您使用/debug：full，请注意/debug：full对JIT优化代码的速度和大小有一些影响，对代码质量也有一些影响。我们建议使用/debug：pdbonly或no PDB来生成发布代码。
/debug：pdbonly和/debug：full之间的一个区别是，使用/debug：full编译器会发出一个DebuggableAttribute，它用于告诉JIT编译器调试信息可用。
那现在什么是真的？
1.Pdb-only-在.NET 2.0之前，它有助于调查已发布产品（客户机器）的崩溃转储。但它不允许附加调试器。这不是.NET 2.0的问题。这是完全一样的 *。
1.Full-这有助于我们调查崩溃转储，也允许我们将调试器附加到发布版本。但与MSDN提到的不同，它不会影响性能（自.NET 2.0以来）。它与Pdb-only完全相同。
如果它们是完全相同的，为什么我们有这些选择？John Robbins（windows调试之神）found out这些都是历史原因。
在.NET 1.0中存在差异，但在.NET 2.0中没有。看来.NET 4.0也会遵循同样的模式。在与调查小组进行双重检查后，没有任何差异。
控制JITter是否进行调试构建的是/optimize开关。<...>
底线是您希望使用/optimize+和任何/debug开关构建发布版本，以便可以使用源代码进行调试。
然后他继续证明这一点
现在，优化是一个单独的开关/optimize（在visual studio中称为Optimize code）的一部分。
简而言之，无论是将PogInfo设置为pdb-only还是full，我们都会得到相同的结果。建议避免使用None，因为它会使您无法分析已发布产品或附加调试器中的崩溃转储。

您将只需要PDB，但不希望将PDB文件给予给用户。但是，将它们与二进制文件放在一起，可以使您能够将崩溃转储加载到WinDbg等调试器中，并查看程序实际失败的位置。当您的代码在您无权访问的机器上崩溃时，这可能非常有用。
完全调试会将[可重写]属性添加到代码中。这对速度有很大的影响。例如，可以禁用某些循环优化以使单步执行更容易。此外，它对JIT流程的影响很小，因为它打开了跟踪。

我正在编写一个未处理的异常处理程序，当使用pdb-only时，堆栈跟踪包括行号，否则当我选择None时，我只得到Sub/Function的名称。
如果我不分发.pdb文件，即使是只使用PDB构建，我也不会在堆栈跟踪中获得行号。
因此，我将沿着来自VB应用程序的exe分发（XCOPY部署在LAN上）PDB。