ASP.NET 3.5：在生产环境中设置 debug=true 有明显的优势吗？答案

【问题标题】：ASP.NET 3.5: Is there a distinct advantage to having debug=true in a production environment?ASP.NET 3.5：在生产环境中设置 debug=true 有明显的优势吗？
【发布时间】：2011-04-10 23:24:52
【问题描述】：

所有答案都指向“不！”。但是，有些人说，当服务器发生错误时，启用调试很方便。我不确定他们的意思。人们真的调试实时服务器代码吗？老实说，我什至不知道你可以。在我工作的网站上，我们使用 ELMAH 进行错误报告。当发生服务器错误时，我们会通过电子邮件收到完整的堆栈跟踪。在大致了解错误发生的位置和方式后，我将打开包含当前部署到生产环境的所有代码的本地解决方案并在本地进行调试。我从来没有真正调试过服务器本身的代码，所以我不确定人们的意思。

我之所以问这个问题是因为我今天刚刚在整合 web.config XML 时发现 debug=true 存在于登台和生产环境的 web.config 文件中。几年前肯定是这样的，我想知道关闭它会给我们带来什么好处。自项目开始以来启用两年多后如果关闭可能会中断的调试是否可能取决于打开的调试？

【问题讨论】：

您可能还对this blog post 感兴趣，以防您与认为这是个好主意的人进行讨论。他基本上管理着构建所有这些东西的团队，因此值得听取建议。他还链接到 this 博客文章，其中更详细地说明了为什么这是一个坏主意。

标签： asp.net debugging

【解决方案1】：

关闭它应该没问题，您应该会获得轻微的性能提升。听起来您正在使用 ELMAH 做正确的事情。我想不出你为什么要在生产中打开它的充分理由……希望对您有所帮助。

【讨论】：

我想我真正想知道的是人们所说的在生产环境中打开它会在站点发生错误时提供便利时的意思。这样的便利存在吗？如果是这样，那么从技术上讲，打开它至少会有一些优势，尽管会以性能为代价。
@user701346：我猜他们会这么说，因为它可以让您将调试器附加到部署到生产环境的应用程序。但是，如果您发现自己要“人......我希望我能加入生产”，那么事情就发生了可怕的可怕错误。

【解决方案2】：

人们谈论的“优势”是当网站发生错误时，默认的 asp.net 错误页面会显示失败的实际代码行。如果您有 debug=false，那么您将看不到任何此类信息。我认为大多数会推荐这样的东西的人要么不了解像 ELMAH 这样的日志框架（因此，如果没有这个，就无法轻易找到站点上的错误原因），或者他们在开始时就把它留在了生产机器上。在他们安装/测试站点时进行项目，然后忘记更改它。

但是，使用适当的日志记录框架，您仍然可以在幕后获得良好的错误信息，而无需以这种方式将其呈现给最终用户。实际上，您不想向最终用户显示此类信息，因为 a) 他们不知道这意味着什么，并且 b) 如果显示代码的敏感方面（信息这可能会帮助某人找到漏洞）。

【讨论】：

【解决方案3】：

所有System.Diagnostic 库都依赖于这个标志。如果您不使用任何此功能，那么您可能看不到任何直接效果，但要查看来自调试功能的其他效果和消息，您需要至少监视 windows 日志文件。

Debug.Assert 和Debug.Fail 之类的功能在您不将调试标志设置为关闭时仍处于活动状态，并且会影响性能，并且如果您不检查 Windows 系统日志文件，可能会产生您永远看不到的小问题.

在我们的库中，它们充满了断言，调试标志很关键。

同样开启 Debug 标志，可能编译器没有进行也会影响性能的优化。

【讨论】：

【解决方案4】：

优点或缺点取决于您如何看待它是 debug="true" 时不缓存 Webresource.axd 类型的文件。您的优势在于每次都拥有最新的文件，而劣势在于每次都拥有最新的文件。

这对于其他第三方压缩/组合类型的模块通常是正确的，因为调试非缩小的 javascript 等更容易，因此它们通常只有在禁用调试后才能正常运行。

【讨论】：