.net - log4net 与 TraceSource

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center以获得指导。

已关闭 10 年前。

在 this thread许多人表示他们使用 log4net。我是 TraceSources 的粉丝，想知道为什么使用 log4net。

这就是我喜欢跟踪源的原因:

• 可插入监听器 - XML、TextFile、Console、EventLog，您自己的
• 可自定义的跟踪开关(错误、警告、信息、详细、开始、结束、自定义)
• 可自定义配置
• 日志应用程序 block 只是一大组 TraceListener
• 事件/范围的关联(例如，将 ASP.NET 请求中的所有日志与给定客户相关联
• 服务跟踪查看器允许您单独可视化针对这些事件的事件
• 所有这些都可以在 app.config/web.config 中进行配置。

由于 .NET 框架内部使用 TraceSources，它还为我提供了一种配置跟踪的一致方法 - 使用 log4net，我必须配置 log4net 以及 TraceSources。

log4net 给了我什么 TraceSources 没有的功能(或者通过编写几个自定义 TraceListener 无法完成的功能)？

Answer 1

在早期 (.NET 1.0)，.NET Framework 中的跟踪非常有限。

例如，TraceSource 分区直到 .NET 2.0 才出现，并且只有四个级别(错误、警告、信息、详细)，尽管如果需要，您可以使用六个 bool 开关进行分区。

log4j 在 Java 中很流行，因此得到了对 .NET 端口的大量支持，一旦它流行起来，它就会保持这种状态，即使人们甚至没有正确使用它(例如，将它包装在单例中)记录器并失去其主要功能)。

不过，我认为 log4net 和其他框架(例如 NLog、Common.Logging 甚至 EntLib)从头开始实现自己的日志系统，即甚至改变在日志中编写日志语句的方式，从而走上了错误的道路。第一名。

我更希望看到努力，特别是自 .NET 2.0 以来，投入到扩展 .NET 中已有内容的坚实基础上。对于确实扩展了现有内容的项目，请查看 CodePlex 上的 Essential Diagnostics 项目 ( http://essentialdiagnostics.codeplex.com/ )。

log4net 的一些优势:

• 如果您运行混合环境并需要一致的日志记录，它与 log4j 类似。

• 与您实现并必须配置每个跟踪源的数量相比，继承设置的自动记录器层次结构非常简洁。 (尽管在某些情况下可能有点过分)。

• log4net 已经有大约 28 个附加程序(相当于跟踪监听器)，而 System.Diagnostics 只有 10 个(但请参阅 Essential.Diagnostics 项目了解更多)，因此，如果您确实认为可能需要 RemoteSyslogAppender、NetSendAppender 、AnsiColorTerminalAppender 或 TelnetAppender，那么您很幸运。

缺点(与 System.Diagnostics 相比):

• 您需要使用不同的日志记录语法，因此如果您已经在使用 source.TraceEvent()，则需要遍历并替换所有内容。

• 这也扩展到不同的关联语法，因此您需要从 CorrelationManager 更改为 log4net 上下文。

• 不容易与框架跟踪(例如 WCF)集成。

• 对事件 ID 的支持很差(需要使用单独的扩展项目 IEventLog)。

• 尚不支持 Windows (Vista) 事件跟踪或服务跟踪查看器 XML 格式。