由于我们可以使用反射器对.Net应用程序进行反向工程，是否有任何理由不将pdb文件与该应用程序一起提供？如果我们确实将它们与之一起运送，则堆栈跟踪中将包含有问题的行号，如果它崩溃则很有用。

每个评论只能输入1个理由进行投票。

解决方案

随应用程序一起提供PDB可以简化逆向工程，因为它包含局部变量/对象名称，函数原型等。

为什么要运送比我们需要的更多的东西？

除了他们在任何严肃的项目中都非常沉重的事实之外？不，如果我们不介意人们对软件进行逆向工程，则没有任何理由。

Reflectors可以获取.NET应用程序的MSIL代码的高级版本，但这并不意味着它一定是可用的/可破解的……如果没有private的名称，那么很多代码对于随意阅读是没有意义的变量和函数以及.NET Reflector在没有PDB文件的情况下无法访问的其他内容。

显然，如果我们使用任何不错的混淆器(我个人喜欢{smartassembly}，但由于它缺乏交叉混淆)，那么我们将失去其所有保护，仅仅是为了增加行号，这不是真正公平的权衡。

无论如何，行号被高估了！

大多数人都希望发布优化的版本。但是，如果交付的Pdb具有优化的构建，则获得的源行号可能会关闭。

运送pdb不会给用户带来任何额外的便利。因此，没有理由在应用程序中附带pdb文件。此外pdb文件通常具有较大的大小。

而不是运送pdb文件，我们应该使用本地Microsoft Symbol Server快速访问与错误报告相对应的pdb文件。在这里，我们可以找到有关如何使用Symbol Server的详细说明。