什么时候应该使用Tracing vs Logger.NET，Enterprise Library，log4net或Ukadc.Diagnostics？
如何选择标准跟踪，Logger.NET，Enterprise Library，log4net或Ukadc.Diagnostics？什么时候应该使用Tracing vs Logger.NET，Enterprise Library，log4net或Ukadc.Diagnostics？
是否存在一种比另一种更合适的情况？那会是什么？ （ASP.NET，控制台应用程序，Azure Cloud，SOHO，Enterprise ...）
有什么好处或缺点？
我错过了其他主要的日志框架吗？
这里有这么多类似的问题：
- Logging best practices
- log4net versus TraceSource
- Silverlight Logging framework and/or best practices
- log4net vs. Nlog
- What's the point of a logging facade?
- C# Logging. What should I use?
您错过了几个常用的日志框架。下面是常用的框架的列表，其中您列举了一些：
记录抽象：
系统。诊断插件：
其他
CodePlex从一对夫妇的其他日志框架（我见过他提到重新上SO）：
你为什么会选择一个比其他？这是一个艰难的。很多都是个人喜好。其中一些是技术（或功能）优势。
任何日志框架（特别是第三方日志框架）的一个明显缺点是支持的质量。如果您遇到log4net，NLog，Common.Logging等问题会怎么样？你能从这些框架的开发者那里得到解决吗？这可能不是非常重要，因为源代码可用于这些框架。但是，您可能不希望“继承”源代码树，只是为了修复或添加增强功能。我会说框架是如此可扩展的，许多增强功能可以通过正常的扩展点添加。
如果您阅读了我上面发布的链接，我认为仅仅根据有利提及的数量来说，公平地说log4net将是明确的“胜利者”。它将被更频繁地提及为历史采伐喜好以及许多人选择继续使用的内容。
NLog有它的支持者，虽然它们非常相似，但它似乎并没有渗透，或者说log4net的“头脑”意识。 NLog的功能与log4net非常相似，它具有最近经历了重要开发周期的额外优势。
企业图书馆经常被吹捧为一个不错的选择，但几乎同样被经常吹捧为可怕的选择。也许它的一些负面声誉可能不是很好的早期版本？也许现在更好？
System.Diagnostics通常被推荐为一个合理的选择，至少有三个好处：没有第三方依赖性，很多Microsoft组件都装有System.Diagnostics，它很容易扩展（大概是添加一些已经存在的功能“免费”在像log4net和NLog的框架中？）。如果您使用System.Diagnostics，我认为共识将（如我的建议）使用TraceSource对象而不是Trace.WriteLine/Debug.WriteLine。
还要注意System.Diagnostics和WCF一起工作良好。可以使用System.Diagnostics记录WCF消息流量，并且WCF还会跨WCF服务边界调用传播System.Diagnostics活动信息（System.Diagnostics.CorrelationManager.ActivityId）。
我不太确定log4net应该继续保持其最受青睐的状态。 As has been noted elsewhere here on SO, log4net does not seem to be undergoing a lot of development recently（请注意，我认为“log4net已经死了”是夸张的），而NLog 2.0目前处于测试阶段，预计2011年第一季度的最终版本（更新日期：2011年7月17日的NLog 2.0 was released）。这是否使得NLog成为比log4net更好的选择？我不知道，但我认为，相对而言，NLog在两者之间进行选择时至少应该得到同等的考虑，并且可能应该是新开发的推定最喜欢的事情，至少在log4net开发显示出更多生命迹象之前。
log4net和NLog都提供了非常灵活的配置选项。它们允许您在日志语句的定义中具有非常精细的粒度（通过为每种类型定义日志记录器的“标准”模式）。它们还允许您开发自己的“日志记录目标”对象（log4net Appenders和NLog目标）和“格式化”对象（log4net模式转换器和NLog LayoutRenderers），从而轻松扩展库。
除了日志框架选择外，一些（很多？）倡导通过使用抽象层将应用程序代码与特定日志框架的硬依赖关系隔离。这可以采用您实现的自己的ILogger接口的形式，也许在现有的框架之上。将来，您可以通过在不同的框架上实现您的ILogger来更改框架。或者，您可以使用DI/IoC在代码中注入“ILogger”。许多DI/IoC框架提供了一个内置的ILogger抽象，可以配置为使用log4net，NLog或企业库，或者您可以编写自己的ILogger实现并注入）。谁关心实施是什么？另一种将代码与特定日志框架硬依存的方法是通过使用现有的日志抽象框架，如Common.Logging或SLF。好处是，您的应用程序不再依赖于特定的日志记录框架。然而，有些人会说你刚刚为另一个（日志抽象框架）交易了一个依赖项（在日志框架上）。有关日志抽象
另外两个注意事项：
一个好的日志抽象应该让你捕捉来自不同的日志框架输出相同的输出文件。 Common.Logging称之为“桥接”。假设您已经使用CommonLogging编写了一个应用程序，并由NLog支持。现在说您正在使用直接使用log4net编写的第三方类库。使用桥接系统，您可以捕获log4net输出（通过自定义appender）并通过Common.Logging重新路由它，以便第三方类库的日志输出可以在应用程序日志输出的上下文中查看。
使用日志抽象还允许您在开发过程中“测试驱动器”日志框架。你可能会开始认为log4net是该走的路，但你想让自己开放尝试NLog。使用日志抽象在两者之间切换相对比较容易。最终，您可以选择哪种日志框架，但同时，您可以编写大量不依赖于特定日志框架的代码。
，你可能会选择在一个又一个框架的另一个原因是在你的工作环境。如果您已经在使用企业库的一部分，那可能足以推动您使用企业库日志记录。
如果您在Silverlight中开发，该怎么办？你可以选择使用类似Clog - part of Calcium的东西。您也可以选择使用与Silverlight和WP7兼容的NLog 2.0。
System.Diagnostics插件（Ukadc.Diagnostics，Essential.Diagnostics）。这些本身不是日志框架。相反，它们表示可用于现有System.Diagnostics框架的有用对象和扩展点的集合。在我看来，最好的事情之一就是每个插件都增加了格式化日志记录输出的能力，类似于如何使用log4net和NLog格式化它。我没有使用Essential.Diagnostics，但我已经试用了Ukadc.Diagnostics，并认为它非常酷。编写自己的“格式化令牌”甚至很容易。
我不知道这是否完全回答了你的问题（反正这个问题相当广泛），但我认为这里有很多值得思考的东西。
我刚刚在VS2010中开始使用log4net，发现它对System.Web有一个依赖......这使它与“.NET xx Client Profile”框架目标不兼容......考虑到某人在这里发布了什么Windows更新使用客户端配置文件作为可选的.NET可再发行组件，这意味着如果您想让代码在大多数计算机上运行，log4net不再是您首选的记录器......
感谢您其他选项 - 我会检查出来...
我不是log4j或log4net的粉丝。我喜欢java.util.net日志工具，因此我大部分都是在名为NetLog的github项目https://github.com/greggwon/NetLog/上重新创建它。随时提供反馈。我想花点时间在logging.properties文件的liu中放入基于ConfigurationManager的配置。使用java.util.logging，使用命令行属性设置来指定日志配置所在的位置总是很容易。如果不使用ConfigurationManager，使用.net会更加痛苦。为CM提供支持，将为记录器和处理程序之间的某些不同关系打开大门，这可能会使某些事情变得更好。
NetLog包含一个EventLogHandler，它将登录到系统事件日志。它还有一个Level.EventLog级别设置为低于“警告”，这将允许您在不使用“警告”或“严重”的情况下拥有指定EventLog的命名“级别”。我还有一个TCPSocketHandler，它可以让你远程登录到“日志记录”，这样你就可以在窗口上有一个“尾巴”，没有“尾巴”程序可用。
我想补充微软的Build 2013大会学到了一些东西：
log4net的在重负载下已经写入文件，主要是因为这个过程是同步的。在某些情况下可能会出现争用和超时。这可以使用AppDynamics或任何其他类似的工具进行验证。
NLog没有在负载情况下实现排队，IO调用堆栈起来。据微软称，ETW使用高效的内核环缓冲区。 .NET 4.5和事件日志框架结合Semantic Logging Application Bock (AKA SLAB)将使这个更有效率。
看看GitHub上的NetLog.Logging包，它是我的创建。它有一个监控应用程序，并遵循java.util.logging API范例，因为这就是我喜欢使用的。它具有用于访问“书写”的自旋锁，并且锁持有人在继续之前写入排队的所有记录，达到极限。这将允许日志减少基于I/O的争用并提供良好的折衷。
出于某种原因，System.Diagnostics不支持将所有跟踪输出定向到单个侦听器的方式。如果您希望将多个源指向同一个侦听器，则必须按名称明确列出每个源。
在一个有很多依赖关系的大系统中，你可能不知道所有的来源，你可能不关心。你只是想让输出看看下面发生了什么。必须为每个源单独设置侦听器，使得使用System.Diagnostics难以在大型系统中使用。
log4net不仅支持根级别的appender（侦听器），还支持分层日志记录，允许您将逻辑集的日志记录配置为一个组。在我看来，这使得log4net成为明智的选择。
+1百万，感谢您的回答，似乎来自经验和广泛的知识！ – LamonteCristo 2011-01-24 00:40:58
我想对关闭这个问题进行投票，因为这已经在SO这里问过数百次了。但是，您的答案非常好。它确实增加了这里给出的答案的价值。出于这个原因，没有投票结束，但为你+1。 – Steven 2011-01-25 14:25:27
@Steven - 感谢您的客气话！ – wageoghe 2011-01-26 03:46:28