Visual Studio：发布版本中的调试信息
我很想在发布给客户的版本中包含调试信息。据我所知，唯一的缺点是二进制文件大小增加了 25%。优点是我可以获得立即可用的故障转储，更容易分析。 我愿意接受 25% 的涨幅。还有其他我遗漏的缺点吗？
这是一个 C 项目，我想做的就是链接/调试/生成调试信息
I'm tempted to include debug information in my release builds that go out to customers. As far as I see the only down side is 25% increase in the binary file size. The advantage is that I can get an immediately usable crash dump, much easier to analyze.
I'm willing to live with the 25% increase. Are there any other disadvantages I'm missing?
This is a C project and all I want to do is Linked/Debugging/Generate Debug Info
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
可执行文件的大小增加应远小于 25%。
事实上，我对它增加这么多感到有点惊讶，但一些快速测试表明，至少有一个大型示例项目 (ScummVM) 只需添加
/DEBUG 链接步骤选项（大约增加 8%）。/DEBUG使用 IDE 中的“链接器 | 调试 | 生成调试信息”选项指定。请注意，此设置应该对编译器生成的优化没有影响。我知道指向 .pdb 文件的指针被放入可执行文件中，但没有太多内容。我进行了一些实验，发现启用
/OPT:REF链接器选项将大小差异更改为 10,205,184 与 10,205,696。因此，非/DEBUG构建保持相同的大小，但/DEBUG构建下降到仅 512 个字节（这可以通过指向 .pdb 的指针来解释） - 也许链接器舍入为 512 的某个倍数或其他）。增幅远低于1%。显然，添加/DEBUG会导致链接器保留未引用的对象，除非您还指定/OPT:REF。 （IDE 中的“链接器 | 优化 | 引用”选项）。该程序在没有 .pdb 文件的情况下也可以正常运行 - 如果您想在客户现场提供更好的调试体验，您可以选择将其发送给客户。如果您只是想获得合适的堆栈跟踪，则不需要在客户计算机上拥有 .pdb 文件 - 他们（或您提供的某些工具/功能）可以发送一个转储文件，该文件可以加载到在您的站点上使用可用的 .pdb 文件进行调试器，并获取相同的堆栈跟踪信息端口检验。
当然，需要注意的一件事是您需要将 .pdb 文件与您的版本一起存档。 “Windows 调试工具”包（现已在 Windows SDK 中分发）提供了一个符号服务器工具，以便您可以存档 .pdb 文件并轻松检索它们以进行调试。
我能想到的分发 .pdb 文件的唯一缺点是，如果您担心的话，它可以使您的应用程序的逆向工程变得更容易。请注意，Microsoft 为 Windows 分发符号（使用公共符号服务器 - 以及某些特定版本的完整符号集包）。然而，他们分发的符号确实经过了清理步骤，删除了他们认为敏感的某些项目。您可以使用链接器的
/PDBSTRIPPED选项（IDE 中的“链接器 | 调试 | 剥离私有符号”）执行相同（或类似）的操作。有关该选项删除的内容的详细信息，请参阅MSDN 文档。如果您要分发符号，那么使用该选项可能是合适的。The size of the executable should increase much less than 25%.
I'm actually a little surprised that it increases much at all, but some quick tests show that at least one large example project (ScummVM) increases the .exe from 10,205,184 bytes to 10,996,224 bytes just by adding the
/DEBUGoption to the link step (about an 8% increase)./DEBUGis specified using the"Linker | Debugging | Generate Debug Info"option in the IDE. Note that this settings should have no effect on the optimizations generated by the compiler.I know that a pointer to the .pdb file is put in the executable, but there's not much to that. I experimented a bit and found that enabling the
/OPT:REFlinker option changed the size difference to 10,205,184 vs. 10,205,696. So the non/DEBUGbuild stayed the same size, but the/DEBUGbuild dropped to only 512 bytes larger (which could be accounted for by the pointer-to-.pdb - maybe the linker rounds to some multiple of 512 or something). Much less than 1% increase. Apparently, adding/DEBUGcauses the linker to keep unreferenced objects unless you also specify/OPT:REF. ("Linker | Optimization | References"option in the IDE).The program will run fine without the .pdb file - you can choose to send it to customers if you want to provide a better debugging experience at the customer site. If you just want to be able to get decent stack traces, you don't need to have the .pdb file on the customer machine - they (or some tool/functionality you provide) can send a dump file which can be loaded into a debugger at your site with the .pdb file available and get the same stack trace information port-mortem.
Of course, one thing to be aware of is that you'll need to archive the .pdb files along with your releases. The "Debugging Tools for Windows" package (which is now distributed in the Windows SDK) provides a symbol server tool so you can archive .pdb files and easily retrieve them for debugging.
The only drawback that I can think of to distributing .pdb files is that it can make reverse engineering your application easier, if that's a concern for you. Note that Microsoft distributes symbols for Windows (using a public symbol server - as well as packages of the full symbols sets for some specific releases). However, the symbols they distribute do get run through a sanitizing step that removes certain items they consider sensitive. You can do the same (or similar) using the linker's
/PDBSTRIPPEDoption ("Linker | Debugging | Strip Private Symbols"in the IDE). See the MSDN documentation for details on what the option removes. If you're going to distribute symbols, it's probably appropriate to use that option.根据 Visual Studio 2005 文档 Visual Studio 2005 停用文档：
就我而言，当我启用两者时它会有所帮助：
According to the Visual Studio 2005 documentation at Visual Studio 2005 Retired documentation:
In my case it helped when I enabled both:
您没有提及您使用的语言，并且 C++ 与 C# 可能会有不同的答案。
我不能 100% 确定您正在考虑做出什么改变。您是要告诉 Visual Studio 进行标准调试编译并发布它，还是要在发布编译中编辑几个设置？在我看来，仔细修改发布版本中的几个设置是最好的方法。
无论您最终得到什么，我都会确保打开优化，因为这可以对编译代码的性能产生重大影响。
You don't mention what language you're in, and there might be different answers for C++ vs. C#.
I'm not 100% sure what change you're considering making. Are you going to tell Visual Studio to make its standard Debug compile, and ship that, or are you going to edit a couple settings in the Release compile? A careful modification of a couple of settings in the Release build strikes me as the best approach.
Whatever you end up with, I'd make sure that optimizations are turned on, as that can make a significant difference in the performance of the compiled code.
我总是发送调试版本，而不是发布版本。我想不出有什么缺点，优点就如你所说。
I always send out the debug build, never the release build. I can't think of any disadvantages, and the advantages are as you mention.