.NET BCL中的跟踪与调试

好像是

System.Diagnostics.Debug,和

System.Diagnostics.Trace

在很大程度上是相同的,有一个值得注意的例外,就是在发布配置中编译了Debug使用.

你何时会使用一个而不是另一个？到目前为止我唯一能解决的问题就是你使用Debug类来生成只在调试配置中看到的输出,而Trace将保留在发布配置中,但这并没有真正回答我的头.

如果您要对代码进行检测,为什么要使用Debug,因为可以在不重新编译的情况下关闭Trace？

1> Jared..：

---

主要区别在于您指出的内容:Debug不包含在发行版中,而Trace是.

据我所知,预期的差异在于,开发团队可能会使用Debug来发布丰富的描述性消息,这些消息可能对产品的消费者来说过于详细(或显露),而Trace旨在发出这样的信息.更具体地适用于检测应用程序的消息.

为了回答你的上一个问题,我想不出有什么理由使用Debug来检测我打算发布的一段代码.

希望这可以帮助.

---

我完全不同意这个答案.Trace是一个比Debug更低的级别,不应该在生产中使用.根据我的经验,trace在方法开始时使用,或者在通过工作流时"跟踪"工作,并在某些方面显示调用堆栈.以上和包括Info在内的所有内容都应该是生产中使用的唯一级别.那就是信息,警告,错误,致命.

---

跟踪是**应该用于生产的东西.非常重要的是****的每个**子系统都包含跟踪代码.每个硬盘驱动器寻找,每个内存分配,每个中断,CPU上下文切换,每个线程调度都有跟踪代码.事件跟踪Windows平台(ETW)是一个非常轻量级的跟踪系统,任何人都可以随时启用Windows PC.[System.Diagnostics.Tracing.EventSource](https://msdn.microsoft.com/en-us/library/system.diagnostics.tracing.eventsource.aspx)是将跟踪事件发送到ETW的托管方式.

---

@VincePanuccio我相信你在谈论实际的日志记录级别,这个问题是在System.Diagnostics命名空间中讨论Debug和Trace类.您正确地考虑了每个日志级别的不同优先级.

---

这些天(4年后)我对Trace实际上有不同的意见,这与@Jared给出的答案更为一致.考虑到我与之合作过的不同团队使用Trace,它作为一种仪器工具非常有用.MSDN上有关于Trace类的一些很好的信息https://msdn.microsoft.com/en-us/library/system.diagnostics.trace(v=vs.110).aspx谈论从"我完全不同意来到整个圈子" ":)

---

Microsoft关于[跟踪和检测应用程序]的文档（https://docs.microsoft.com/zh-cn/dotnet/framework/debug-trace-profile/tracing-and-instrumenting-applications）帮助我更好地理解了差异。

2> 小智..：

---

调试用于纯粹的调试目的.它在调试执行(调试模式)中发出丰富的消息.

Trace有助于应用程序调试,错误修复和分析(发布后).

Debug类在发布模式下没有用.