我有一个VB.net应用程序。目前，发布版本的应用程序没有PDB文件。这导致我的错误日志缺乏有用的细节，比如行号。 我正在考虑在将来的构建中包含PDB文件，但我想知道这样做的优点和缺点是什么（从性能、大小和代码安全方面）。
包含PDB文件在发布应用程序中的优缺点
10
- zeocrash
3
你究竟想通过PDB文件实现什么目标？除非你混淆了代码，否则使用托管代码已经可以得到很好的堆栈跟踪（我认为PDB会使混淆无效...）。你唯一能获得的优势是“隐藏”的符号，例如局部变量和参数名称。 - Krumelur
糟糕。我喜欢这个问题，但它已经在这里被问过了：https://dev59.com/q3M_5IYBdhLWcg3wmkau - David
2参数名称和行号非常有用。我们的应用程序是由几个不同版本的VB的开发人员构建的，目前我们在堆栈中只有过程的名称，但是拥有更多的数据会更好。 - zeocrash
4个回答
13
我知道我会被打，但是...
我同意Dave Markle的观点，但我想补充一点，发布PDB文件的好处是，正如你所说，非常适合调试。
话虽如此，我不销售软件，我编写的代码都是为我们公司内部使用的。在这种情况下，我认为将调试代码与PDB文件放入生产环境中并不存在问题。我从未见过性能降低，而且老实说，我们的用户很少给我们提供正确的信息，如果他们遇到未处理的异常。当然，我们尝试正确地处理异常，但是错误总是会发生。我们的策略是向所有项目添加全局异常处理程序，并将这些事件记录到数据库中。这些错误包含行号，因为我们包括调试文件，结果我们能够快速识别和回应错误代码，修复它，并获得更多无错误的应用程序。对于我们的用户来说，这是一个巨大的受益，我不想舍弃它。
所以，如果你处于类似的情况下，在这种情况下，请忘记官方立场，继续发布带有pdb文件的应用程序，但需要注意一个重要的限制条件。
务必确保您部署的任何Web应用程序完全处理所有异常，并且您没有意外地在标准Asp.NET错误页面中公开代码行。
- David
11
当您部署应用程序的调试符号时，有些人可能觉得不希望被人轻易的反向工程化。此外，您需要部署更多的文件，您的可部署项目变得更大了。PDB文件本身并不会使应用程序变慢，因为传送PDB并不总是放弃优化（只要小心一点 - 默认的“Debug”项目设置通常不会在生成PDB时优化您的输出内容）。
- Dave Markle
2
为您的发布版本创建PDB文件，但不要将它们发布。请将PDB文件与相应的构建和源代码保存在安全的地方。如果您遇到实时崩溃或类似情况，可以使用这些PDB文件使用Windows调试工具或Visual Studio进行死后调试。
- Polyfun
2
1我们尝试着处理所有的异常。因此，我们不进行事后调试。对于处理过的异常，我们将堆栈跟踪记录在数据库中。 - zeocrash
2当你的应用程序挂起时，即使没有任何异常抛出，事后调试也非常有用。您可以捕获挂起进程的迷你转储，然后使用 pdbs 和源代码远程调试它。 - Polyfun
0
我发现在发布版本中也构建调试信息非常有用 - 它有助于捕获错误。这不会使程序运行变慢。但是，如果您不希望其他人能够更轻松地进行逆向工程，则不应将PDB文件与应用程序一起发布。只需将其提供给测试人员。
- darklon
1
该应用程序是一个内部应用程序。它只会在我们公司内部使用。用户限制防止用户能够反向工程我们的代码。 - zeocrash
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接