释放生成.pdb文件，为什么？ [英] Release generating .pdb files, why?

问题描述

为什么Visual Studio 2005在版本中编译时会生成 .pdb 文件？我不会调试发布版本，为什么要生成？

解决方案

因为没有PDB文件，无法通过除地址级调试之外的任何内容调试发布构建。优化实际上对您的代码执行了一些操作，如果发生错误（例如异常），很难找到凶手被抛出）。即使设置断点是非常困难的，因为源代码行不能与生成的汇编代码（或甚至以相同的顺序）与一对一匹配。 PDB文件可帮助您和调试器，使死后调试变得更加容易。

您提到，如果您的软件准备发布，您应该已经完成​​了那你的调试。虽然这是肯定的，但有几点要牢记：

1. 你也应该 em>使用Release构建测试和调试应用程序（在您释放之前）。这是因为在调试配置下，默认情况下停止优化（有时会被禁用）有时会导致出现无法捕获的细微错误。当您进行此调试时，您将需要PDB符号。




2. 客户经常报告仅在理想条件下出现的边缘案例和错误。这些是几乎不可能在实验室中复制的东西，因为它们依赖于用户机器的一些重复配置。如果他们特别有帮助的客户，他们将报告抛出的异常并提供堆栈跟踪。或者他们甚至可以借用他们的机器来远程调试软件。在任何一种情况下，您都希望PDB文件可以帮助您。




3. 剖析应始终 启用优化构建。再次，PDB文件派上用场，因为它们允许将配置文件的描述文件映射回您实际写入的源代码。

您不能返回并在编译之后生成PDB文件 ^* 如果在构建期间不创建它们，你失去了机会。它不会伤害任何东西来创建它们。如果你不想分发它们，你可以从二进制文件中简单地省略它们。但如果你以后决定要他们，你就不幸了。 更好地总是生成它们并归档副本，以防您需要它们。

如果你真的想关闭它，那就是总是一个选择。在您的项目的属性窗口中，将Debug Info选项设置为none，以便您想要更改的任何配置。

请注意，但是，Debug和释放配置 默认使用不同的设置来发布调试信息。您将要保留此设置。对于Debug构建，Debug Info选项设置为full，这意味着除了PDB文件外，调试符号信息嵌入到程序集中。您还可以获得支持酷炫功能（如编辑和继续）的符号。在释放模式下，选择pdb-only选项，它似乎听起来只包含PDB文件，而不影响程序集的内容。所以它不像在 / bin 目录中仅存在或不存在PDB文件那么简单。但假设您使用pdb-only选项，PDB文件的存在决不会影响代码的运行时性能。

_{^* 作为 Marc Sherman在评论中指出 ，只要您的源代码没有更改（或者您可以从版本控制系统检索原始代码），则可以重建它并生成匹配的PDB文件。至少，通常。这大部分时间都很好，但是编译器不保证每次编译相同的代码生成相同的二进制代码，所以可能}是微妙的差异。更糟糕的是，如果您在此期间对工具链进行了任何升级（例如对Visual Studio应用服务包），则PDB的可能性更小。为了保证可靠的生成PDC文件，您不仅需要存档版本控制系统中的源代码，还需要存档整个构建工具链的二进制文件，以确保您能准确地重新创建构建环境的配置。不用说，简单地创建和归档PDB文件要容易得多。

Why on earth does Visual Studio 2005 generate the .pdb files when compiling in release? I won't be debugging a release build, so why are they generated?

解决方案

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 make the point that if your software is ready for release, you should have done all your debugging by then. While that's certainly true, there are a couple of important points to keep in mind:

1. 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.

2. 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.

3. 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.

You can't go back and generate the PDB files after the compile.^* If you don't create them during the build, you've lost your opportunity. It doesn't hurt anything to create them. If you don't want to distribute them, you can simply omit them from your binaries. But if you later decide you want them, you're out of luck. Better to always generate them and archive a copy, just in case you ever need them.

If you really want to turn them off, that's always an option. In your project's Properties window, set the "Debug Info" option to "none" for any configuration you want to change.

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.}

这篇关于释放生成.pdb文件，为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！