在多项目解决方案中，您通常希望有一个完全不生成PDB或XML文件的配置。与其将每个项目的Debug Info属性更改为none，我认为添加一个仅在特定配置中工作的构建后事件会更方便。

不幸的是，Visual Studio不允许您为不同的配置指定不同的构建后事件。所以我决定手动做这件事，通过编辑启动项目的csproj文件，并添加以下内容(而不是任何现有的PostBuildEvent标记):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

不幸的是，这将使后构建事件文本框为空白，在其中放入任何内容都可能产生不可预测的结果。

在多项目解决方案中，您通常希望有一个完全不生成PDB或XML文件的配置。与其将每个项目的Debug Info属性更改为none，我认为添加一个仅在特定配置中工作的构建后事件会更方便。

不幸的是，Visual Studio不允许您为不同的配置指定不同的构建后事件。所以我决定手动做这件事，通过编辑启动项目的csproj文件，并添加以下内容(而不是任何现有的PostBuildEvent标记):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

不幸的是，这将使后构建事件文本框为空白，在其中放入任何内容都可能产生不可预测的结果。

PDB可以为发布生成，也可以为调试生成。这是设置在(在VS2010中，但在VS2005中必须相似):

项目→属性→构建→高级→调试信息

只需将其更改为None。

调试符号(.pdb)和XML文档(. XML)文件占总大小的很大比例，不应该成为常规部署包的一部分。 但如果需要的话，应该可以访问它们。

一种可能的方法是:在TFS构建过程的末尾，将它们移动到一个单独的工件。

为什么您如此确定您不会调试发布版本?有时(希望很少，但确实会发生)，您可能会从客户那里得到一个缺陷报告，由于某些原因(不同的时间，小的不同行为或其他原因)，该报告在调试版本中是不可重复的。如果该问题在发布版本中是可重复的，那么您将很高兴拥有匹配的pdb。

Because without the PDB files, it would be impossible to debug a "Release" build by anything other than address-level debugging. Optimizations really do a number on your code, making it very difficult to find the culprit if something goes wrong (say, an exception is thrown). Even setting breakpoints is extremely difficult, because lines of source code cannot be matched up one-to-one with (or even in the same order as) the generated assembly code. PDB files help you and the debugger out, making post-mortem debugging significantly easier.

您指出，如果您的软件已经准备好发布，那么您应该在发布之前完成所有的调试工作。虽然这是正确的，但有几个重要的要点需要记住:

You should also test and debug your application (before you release it) using the "Release" build. That's because turning optimizations on (they are disabled by default under the "Debug" configuration) can sometimes cause subtle bugs to appear that you wouldn't otherwise catch. When you're doing this debugging, you'll want the PDB symbols. Customers frequently report edge cases and bugs that only crop up under "ideal" conditions. These are things that are almost impossible to reproduce in the lab because they rely on some whacky configuration of that user's machine. If they're particularly helpful customers, they'll report the exception that was thrown and provide you with a stack trace. Or they'll even let you borrow their machine to debug your software remotely. In either of those cases, you'll want the PDB files to assist you. Profiling should always be done on "Release" builds with optimizations enabled. And once again, the PDB files come in handy, because they allow the assembly instructions being profiled to be mapped back to the source code that you actually wrote.

在编译之后，您不能返回并生成PDB文件。*如果你不在构建过程中创建它们，你就失去了机会。创造它们不会伤害任何东西。如果您不想分发它们，您可以简单地将它们从二进制文件中删除。但如果你后来决定要它们，那你就不走运了。最好总是生成它们并存档一份副本，以备不时之需。

如果你真的想关掉它们，这总是一个选择。在项目的属性窗口中，将“调试信息”选项设置为“none”，用于您想更改的任何配置。

Do note, however, that the "Debug" and "Release" configurations do by default use different settings for emitting debug information. You will want to keep this setting. The "Debug Info" option is set to "full" for a Debug build, which means that in addition to a PDB file, debugging symbol information is embedded into the assembly. You also get symbols that support cool features like edit-and-continue. In Release mode, the "pdb-only" option is selected, which, like it sounds, includes only the PDB file, without affecting the content of the assembly. So it's not quite as simple as the mere presence or absence of PDB files in your /bin directory. But assuming you use the "pdb-only" option, the PDB file's presence will in no way affect the run-time performance of your code.

* As Marc Sherman points out in a comment, as long as your source code has not changed (or you can retrieve the original code from a version-control system), you can rebuild it and generate a matching PDB file. At least, usually. This works well most of the time, but the compiler is not guaranteed to generate identical binaries each time you compile the same code, so there may be subtle differences. Worse, if you have made any upgrades to your toolchain in the meantime (like applying a service pack for Visual Studio), the PDBs are even less likely to match. To guarantee the reliable generation of ex postfacto PDB files, you would need to archive not only the source code in your version-control system, but also the binaries for your entire build toolchain to ensure that you could precisely recreate the configuration of your build environment. It goes without saying that it is much easier to simply create and archive the PDB files.