在发布应用程序中包含 PDB 文件的优点和缺点
我有一个 VB.net 应用程序。目前，该应用程序的发布版本是在没有 PDB 文件的情况下生成的。这使我的错误日志缺乏有用的详细信息，例如行号。 我正在考虑将 PDB 文件包含在未来的版本中，但我想知道这样做的优点和缺点是什么（性能方面、大小方面、代码安全方面）
I've got a VB.net application. Currently the release version of the application is produced without a PDB file. This gives me error logs lacking useful details such as line numbers.
I'm looking at including the PDB files with future builds but i'd like to know what the advantages and disadvantages of this are (performance wise, size wise, code security wise)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我知道我会因此而挨打，但是……
我同意 Dave Markle 的观点，但我想补充一点，正如您所说，发布 PDB 文件的一个优点是非常适合调试。
也就是说，我不卖软件，我写的代码都是供我们公司内部使用的。在这种情况下，我认为将调试代码与 PDB 文件一起投入生产不会有问题。我从未见过性能受到影响，而且老实说，如果我们的用户遇到未处理的异常，他们很少向我们提供正确的信息。当然，我们尝试正确处理异常，但如您所知，错误还是会发生。我们的策略是向所有项目添加全局异常处理程序，并将这些事件记录到数据库中。这些错误包含行号，因为我们确实包含了调试文件，因此，我们能够快速识别错误代码并对其做出反应，修复它，并获得更多无错误的应用程序。对我（以及我们的用户）来说，这是一个巨大的好处，我不想没有它。
因此，如果您遇到类似的情况，我建议忘记官方立场（在这种情况下）并继续发布 pdb 文件，但有一个重要的警告。
请务必确保使用 PDB 文件部署的任何 Web 应用程序都完全确保所有异常都得到正确处理，并且不会无意中在标准 Asp.NET 错误页面中暴露代码行。
I know I'm going to get beat up for this but...
I agree with Dave Markle, but I'd like to add that an advantage of publishing the PDB files is, as you said, VERY nice for debugging.
That said, I don't sell software, and the code I write is all for internal use in our company. In this context, I don't see an issue with putting debug code into production, along with the PDB files. I've never seen a performance hit, and in all honesty, our users rarely give us the right information if they encounter unhandled exceptions. Of course, we try to handle exceptions correctly, but as you know, errors will happen. Our strategy is to add a global exception handler to ALL projects, and log those events tot he database. These errors contain the line numbers because we do include the debug files, and as a result, we are able to quickly identify and react to bad code, fix it, and get more bug-free applications. To me (and to our users) this is a HUGE benefit that I wouldn't want to do without.
So if you're in a similar situation, I say forget the official stance (in this one case) and go ahead and publish the pdb files with ONE important caveat.
Be darn sure that any web application you deploy with the PDB files, be completely sure that ALL exceptions are handled properly, and you're not inadvertently exposing lines of code in a standard Asp.NET error page.
当您为应用程序部署调试符号时，有人很容易对您的工作进行逆向工程，有些人认为这是不受欢迎的。同样，您必须部署更多文件，并且您的可部署项目也会变得更大。 PDB 文件本身不会导致应用程序变慢，因为传送 PDB 并不总是排除放弃优化（您只需小心 - 默认的“调试”项目设置往往不会优化您的输出）生成 PDB）。
When you deploy your debug symbols for your application, it becomes really easy for someone to come along and reverse-engineer your work, which some people find undesirable. Likewise, you have to deploy more files and your deployable project gets bigger. The PDB files themselves don't cause the app to get any slower, as shipping a PDB doesn't always preclude forgoing optimizations (you just have to be careful -- the default "Debug" project settings tend to not optimize your outputs when they generate PDBs).
为您的发布版本创建 pdb，但不发布它们。将 pdb 与匹配的构建和源代码保存在安全的地方。如果发生实时崩溃或类似情况，您可以使用 pdb 进行事后调试，方法是使用 Windows 调试工具 或 Visual Studio。
Create pdbs for your release build, but do not ship them. Keep the pdbs somewhere safe with the matching build and source code. If you get a live crash, or similar, you can use the pdbs to do post-mortem debugging using the Debugging Tools for Windows, or Visual Studio.
我发现为发布版本构建调试信息很有用 - 它有助于捕获错误。它不会使程序运行速度变慢。但是，如果您不希望其他人能够更轻松地对其进行逆向工程，则不应将 PDB 文件与您的应用程序一起提供。只给测试人员。
I find it useful to also have debug information built for the Release version - it helps with catching bugs. It doesn't make the program run slower. But you shouldn't ship the PDB file with your application, if you don't want others to be able to reverse-engineer it more easily. Only give it to testers.