8

我对如何使用 .NET Trace 和 Debug 类有点困惑。

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

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

Debug.WriteLine()
Debug.Assert()

另外，我知道当您处于发布配置模式时，调试语句会被忽略，但是如果跟踪语句一直适用，这对性能有何影响？

4

4 回答 4

8

在最简单的层面上，它们有不同的编译开关——即Debug.WriteLine只有当你有编译符号时才会切换 etc DEBUG（对于发布版本来说并不常见），Trace.WriteLine即使在发布版本中通常也会包含 where-as。

该Trace路由具有可定制的跟踪侦听器，可以通过配置进行探测；Debug通常作为侦听器进入调试器。当然，还有 3rd-party 跟踪系统可以提供更大的灵活性。

于 2008-12-31T10:44:14.430 回答
2

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

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

于 2008-12-31T00:24:10.983 回答
2

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

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

于 2008-12-31T00:27:18.307 回答
2

我倾向于在发布环境中使用 Trace（带有关联的 TraceSwitch）来记录工作——对 app.config 的快速调整可以提供不同级别的日志记录，而无需重新编译（这可能会使问题消失） ) 或需要附加调试器。特别适用于无论出于何种原因仅发生在客户机器上的问题——我已经使用它成功地转储了从 FTP 类中注销（回到旧的 Framework 1.1 天），以帮助诊断两家公司之间的网络传输问题

于 2008-12-31T11:05:19.487 回答