Question

我对如何使用.NET Trace和Debug类感到困惑。

为什么要使用Trace而不是Debug？

Trace.TraceError()
Trace.TraceInformation()
Trace.Assert()

Debug.WriteLine()
Debug.Assert()

另外，我了解在Release配置模式下会忽略Debug语句，但如果trace语句一直适用，这对性能有何影响？

Answer 1

在最简单的层面上，它们有不同的编译开关 - 例如，如果你有Debug.WriteLine编译符号（不适用于发布版本），DEBUG等只会切换，其中 - {{1}通常会在发布版本中包含。

Trace.WriteLine路由具有可自定义的跟踪侦听器，可以通过配置进行检测; Trace通常作为监听器进入调试器。当然，第三方跟踪系统提供了更大的灵活性。

Answer 2

您可以使用编译器开关单独打开和关闭它们，如果您转到项目属性的构建页面，那么您有一些复选框。

对我而言，经验法则是我使用debug来获取实际的调试信息，即此时变量x的值是......等，Trace用于通过我的app追踪控制流（更像垃圾邮件）。

Answer 3

正如您所说，Trace调用仅在您处于发布模式时执行。在发布模式下进行编译具有您在最终应用程序中可能需要的一些性能优势，并且可能还有其他原因要您启用发布模式。但是，有时您可能希望将信息记录到跟踪控制台，可以使用SysInternal's DbgView等应用程序查看这些信息。这些通常是您不一定要发送到日志输出的消息，或者您始终希望可用于调试目的的消息，即使用户已关闭日志记录也是如此。

您当然不希望向Trace控制台发送大量信息，因为它会对性能造成影响，但某些关键信息可能是合适的。

Answer 4

我倾向于使用Trace（带有相关的TraceSwitch）在发布环境中进行日志记录工作 - app.config的快速调整可以提供不同级别的日志记录，而无需重新编译（这可能会产生问题）无论如何都要离开）或需要附加调试器。对于仅出于任何原因仅出现在客户机器上的问题特别方便 - 我已经使用它来成功地从FTP类中退出日志（在旧的Framework 1.1天中）以帮助诊断两家公司之间的网络传输问题

跟踪和调试语句

4 个答案: