为什么Visual Studio 2005在发布版中编译时会生成.pdb文件?我不会调试发布版本,那么为什么要生成它们呢?


当前回答

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

其他回答

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

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

只需将其更改为None。

. pdb文件是“程序数据库”的简称。它包含调试器的调试点信息以及所使用或引用的资源。它是在以调试模式构建时生成的。它允许应用程序在运行时进行调试。

在调试模式下。pdb文件的大小增加。它在我们测试应用程序时使用。

pdb文件的好文章。

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

此外,您还可以利用崩溃转储来调试软件。客户将它发送给您,然后您可以使用它来识别源代码的确切版本——Visual Studio甚至会使用崩溃转储提取正确的调试符号集(如果设置正确,还会提取源代码)。请参阅微软关于符号商店的文档。

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