ASP.NET 3.5：在生产环境中使用debug = true有明显的优势吗？

Question

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

我问这个是因为我今天刚刚发现，在整合web.config XML时，调试= true存在于登台和生产环境的web.config文件中。它一定是这种方式已经存在了几年，我想知道通过关闭它会带来什么好处。在项目开始以来启用超过两年后，如果关闭可能会导致调试被打开，可能会有什么可能依赖吗？

Answer 1

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

Answer 2

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

如果您没有将调试标志设置为关闭并影响性能，那么Debug.Assert和Debug.Fail等函数仍处于活动状态，如果您不检查，则可能会创建一些您从未看到的小问题Windows系统日志文件。

在我们的库中，他们充满了断言，调试标志是至关重要的。

同样，当Debug标志打开时，编译器可能不会进行同样影响性能的优化。

Answer 3

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

但是，如果有适当的日志记录框架，您仍然可以在幕后获得良好的错误信息，而不会以这种方式呈现给最终用户。实际上，您不希望向最终用户显示此类信息，因为a）他们不知道这意味着什么，并且b）如果显示代码的敏感方面，它可能是一个可能的安全问题（info这可能有助于某人发现漏洞。）

Answer 4

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

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