问题描述
我有一个记录异常跟踪记录的应用程序，我希望这些堆栈跟踪在生产环境中部署时包括文件名和行号。我想出了如何使用程序集部署调试符号，但是在研究问题的过程中，我遇到了链接到突然出现在我身上：
So based on everyone's answers so far, it seems like this question can be simplified a bit for .NET applications. This bit from the John Robbins blog linked in Michael Maddox's answer kind of leaped out at me:
对我来说，这重申了其他人对Reflector的看法，这意味着真正的问题是对程序集的访问。确定之后，关于PDB的唯一决定就是您是否关心公开文件名，行号和本地变量名（假设您最初并未向最终用户显示堆栈跟踪）。还是我简化得太多了？
To me, this reiterates what others have been saying about Reflector, with the implication being that the real issue is access to the assemblies. Once that's been determined, the only decision to make with respect to PDBs is whether or not you care about exposing file names, line numbers, and local variable names (assuming that you're not showing stack traces to end users to begin with). Or have I oversimplified this too much?
推荐答案
这里是另一个需要考虑的问题：
Here is another question to look at:
有关PDB文件的更多信息：
And more info on PDB files:
通常，我总是在部署中包括pdb文件，其收益太大而无法忽略。
In general, I always include pdb files in my deployments, the gains are too huge to ignore.
如果您从不向用户公开堆栈跟踪信息（通常不应该这样做），则部署PDB文件确实没有任何额外的安全风险。
If you never expose a stack trace to your users (and generally you shouldn't), there isn't really any additional security risk of deploying PDB files.
发生用户可见的堆栈跟踪时，用户可以看到完整的堆栈跟踪，包括您的文件名和文件行号。这样可以使他们对您的应用程序的架构有一些了解，如果被黑客入侵可能会对他们有帮助。
When a user visible stack trace happens, the user can see the full stack trace including your file name and file line numbers. This could give them some idea of how your app is architected which would potentially help them if hacking.
更大的安全威胁类似于，当在您的DLL上使用该反射器时，它们将允许您查看带有或不带有pdb文件的源代码。
A bigger security threat is something like Reflector which when used on your DLLs will allow them to view your source code, with or without pdb files.
这篇关于在生产环境中部署调试符号（pdb文件）有什么风险？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！