我有一个 VB.net 应用程序。目前，该应用程序的发布版本是在没有 PDB 文件的情况下生成的。这给了我错误日志，缺少有用的详细信息，例如行号。我正在考虑将 PDB 文件包含在未来的构建中，但我想知道这样做的优缺点是什么（性能方面、大小方面、代码安全方面）
问问题
6896 次
4 回答
13
我知道我会因此而挨打，但是...
我同意 Dave Markle 的观点，但我想补充一点，正如您所说，发布 PDB 文件的一个优点是非常适合调试。
也就是说，我不卖软件，我写的代码都是供我们公司内部使用的。在这种情况下，我认为将调试代码与 PDB 文件一起投入生产没有问题。我从未见过性能受到影响，老实说，如果我们的用户遇到未处理的异常，他们很少向我们提供正确的信息。当然，我们会尝试正确处理异常，但如您所知，错误会发生。我们的策略是为所有项目添加一个全局异常处理程序，并将这些事件记录到数据库中。这些错误包含行号，因为我们确实包含调试文件，因此，我们能够快速识别错误代码并做出反应，修复它，并获得更多无错误的应用程序。对我（和我们的用户）来说，这是一个巨大的好处，我不想没有。
因此，如果您处于类似情况，我说忘记官方立场（在这种情况下）并继续发布带有一个重要警告的 pdb 文件。
确保您使用 PDB 文件部署的任何 Web 应用程序，完全确保所有异常都得到正确处理，并且您不会无意中在标准 Asp.NET 错误页面中暴露代码行。
于 2010-05-13T10:09:49.410 回答
11
当您为应用程序部署调试符号时，很容易有人过来对您的工作进行逆向工程，有些人认为这是不受欢迎的。同样，您必须部署更多文件，并且您的可部署项目会变得更大。PDB 文件本身不会导致应用程序变慢，因为交付 PDB 并不总是排除之前的优化（您只需要小心 - 默认的“调试”项目设置往往不会优化您的输出，因为它们生成 PDB）。
于 2010-05-13T09:55:08.337 回答
2
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.
于 2010-05-13T10:33:11.610 回答
0
我发现为发布版本构建调试信息也很有用——它有助于捕获错误。它不会使程序运行速度变慢。但是，如果您不希望其他人能够更轻松地对其进行逆向工程，则不应将 PDB 文件与您的应用程序一起提供。仅将其提供给测试人员。
于 2010-05-13T10:10:35.297 回答