我有一个VB.net应用程序。目前,发布版本的应用程序没有PDB文件。这导致我的错误日志缺乏有用的细节,比如行号。 我正在考虑在将来的构建中包含PDB文件,但我想知道这样做的优点和缺点是什么(从性能、大小和代码安全方面)。
我有一个VB.net应用程序。目前,发布版本的应用程序没有PDB文件。这导致我的错误日志缺乏有用的细节,比如行号。 我正在考虑在将来的构建中包含PDB文件,但我想知道这样做的优点和缺点是什么(从性能、大小和代码安全方面)。
我知道我会被打,但是...
我同意Dave Markle的观点,但我想补充一点,发布PDB文件的好处是,正如你所说,非常适合调试。
话虽如此,我不销售软件,我编写的代码都是为我们公司内部使用的。在这种情况下,我认为将调试代码与PDB文件放入生产环境中并不存在问题。我从未见过性能降低,而且老实说,我们的用户很少给我们提供正确的信息,如果他们遇到未处理的异常。当然,我们尝试正确地处理异常,但是错误总是会发生。我们的策略是向所有项目添加全局异常处理程序,并将这些事件记录到数据库中。这些错误包含行号,因为我们包括调试文件,结果我们能够快速识别和回应错误代码,修复它,并获得更多无错误的应用程序。对于我们的用户来说,这是一个巨大的受益,我不想舍弃它。
所以,如果你处于类似的情况下,在这种情况下,请忘记官方立场,继续发布带有pdb文件的应用程序,但需要注意一个重要的限制条件。
务必确保您部署的任何Web应用程序完全处理所有异常,并且您没有意外地在标准Asp.NET错误页面中公开代码行。
当您部署应用程序的调试符号时,有些人可能觉得不希望被人轻易的反向工程化。此外,您需要部署更多的文件,您的可部署项目变得更大了。PDB文件本身并不会使应用程序变慢,因为传送PDB并不总是放弃优化(只要小心一点 - 默认的“Debug”项目设置通常不会在生成PDB时优化您的输出内容)。
我发现在发布版本中也构建调试信息非常有用 - 它有助于捕获错误。这不会使程序运行变慢。但是,如果您不希望其他人能够更轻松地进行逆向工程,则不应将PDB文件与应用程序一起发布。只需将其提供给测试人员。