什么时候应该使用Tracing vs Logger.NET，Enterprise Library，log4net或Ukadc.Diagnostics？
如何select标准跟踪，Logger.NET，企业库，log4net或Ukadc.Diagnostics？
有一种比另一种更合适的情况吗？ 那会是什么？ （ASP.NET，控制台应用程序，Azure Cloud，SOHO，Enterprise …）
有什么好处或缺点？
我错过了其他主要的日志框架吗？
在这里有很多类似的问题：
- logging最佳实践
- log4net与TraceSource
- Silverlightlogging框架和/或最佳做法
- log4net与Nlog
- 伐木外观有什么意义？
- C＃日志logging。 我应该使用什么？
你错过了几个常用的日志框架。 这里列出了一些常用的框架，其中一些是你列出的：
- System.Diagnostics程序
- log4net的
- NLOG
- 企业图书馆
- 对象的家伙
logging抽象：
- Common.Logging
- SLF
System.Diagnostics插件：
- Ukadc.Dianostics
- Essential.Diagnostics
其他
- ELMAH
来自Codeplex的其他一些日志框架（我在这里已经提到过）：
- CuttingEdge.Logging
- 跳虫
为什么你可以select一个呢？ 这是一个艰难的。 很多是个人喜好。 其中一些是技术（或function）优势。
任何日志框架（特别是第三方日志框架）的明显缺点是支持的质量。 如果你有log4net，NLog，Common.Logging等问题怎么办？ 你能从这些框架的开发者那里得到解决吗？ 这可能不是非常重要，因为源代码可用于这些框架。 但是，您可能不希望“inheritance”源代码树，只是为了修复或添加增强function。 我会说框架是如此可扩展的，许多增强可以通过正常的扩展点添加。
如果你阅读我上面发布的链接，我认为完全根据有利提及的数量来说，log4net将是明确的“胜利者”。 这将被提及更多的历史采伐喜爱和许多人会select使用未来。
NLog有它的支持者，即使它们非常相似，它似乎也没有渗透，或者log4net所做的“头脑”意识。 NLog的function非常类似于log4net，它具有最近经历了重大开发周期的额外优势。
企业图书馆经常被吹捧为一个不错的select，但几乎同样被认为是一个可怕的select。 也许它的一些负面声誉可能不是那么好的早期版本？ 也许现在好多了？
System.Diagnostics通常被推荐为一个合理的select，至less有三个好处：没有第三方依赖，许多Microsoft组件都装备了System.Diagnostics，它很容易扩展（大概是增加一些已经存在的“免费”function）在像log4net和NLog的框架？）。 如果您使用System.Diagnostics，我认为共识将（正如我的推荐）使用TraceSource对象，而不是Trace.WriteLine / Debug.WriteLine。
还要注意System.Diagnostics和WCF一起工作。 WCF消息stream量可以使用System.Diagnostics进行logging，WCF还将跨WCF服务边界调用传播System.Diagnostics活动信息（System.Diagnostics.CorrelationManager.ActivityId）。
我不太确定log4net应该继续保持最受欢迎的状态。 正如在这里其他地方已经注意到的，log4net最近似乎没有经过很多的发展 （注意，我认为“log4net已经死了”是夸张的），而NLog 2.0目前处于testing阶段，预计2011年第一季度的最终版本（更新：NLog 2.0 于2011年7月17日发布） 这是否使得NLog成为比log4net更好的select？ 我不知道，但我认为相对而言，NLog在select二者时至less应该得到同样的考虑，可能应该是新发展的推定，至less在log4net开发显示出更多的生命迹象之前。
log4net和NLog都提供了非常灵活的configuration选项。 它们允许你在日志语句的定义中有非常精细的粒度（通过定义每种types的日志logging器的“标准”模式）。 它们还允许您开发自己的“日志logging目标”对象（log4net Appenders和NLog目标）和“格式化”对象（log4net模式转换器和NLog LayoutRenderer），从而轻松扩展库。
除了日志框架select之外，一些（很多？）倡导通过使用抽象层将应用程序代码与特定日志框架的硬依赖关系隔离。 这可以采用你自己实现的ILogger接口的forms，也许在现有的框架之上。 将来，您可以通过在不同的框架上实现您的ILogger来更改框架。 或者，您可以使用DI / IoC在代码中注入“ILogger”。 许多DI / IoC框架提供了一个内置的ILogger抽象，可以configuration为使用log4net，NLog或企业库，或者您可以编写自己的ILogger实现并注入）。 谁关心实施是什么？ 另一种将代码从一个特定的日志框架硬依赖的方法是通过使用现有的日志抽象框架，如Common.Logging或SLF。 好处是，您的应用程序不再依赖特定的日志logging框架。 然而，有些人会说，你只是为另一个（日志抽象框架）交易一个依赖项（在一个日志框架上）。
关于伐木抽象的另外两个注意事项：
-
一个好的日志抽象应该允许你在同一个输出文件中捕获来自不同日志框架的输出。 Common.Logging称之为“桥接”。 假设您已经使用CommonLogging编写了一个应用程序，并由NLog支持。 现在说您正在使用直接使用log4net编写的第三方类库。 使用桥接系统，您可以捕获log4net输出（通过自定义appender），并通过Common.Logging重新路由它，以便可以在应用程序日志输出的上下文中查看第三方类库的日志输出。
-
使用日志抽象还允许您在开发过程中“testing驱动器”日志框架。 你可能会开始认为log4net是这样的，但是你想让自己开放来尝试NLog。 使用日志抽象，在两者之间切换相对比较容易。 最终，您可以select哪个日志框架，但同时，您可以编写不依赖任何特定日志框架的代码。
你可能select一个框架的另一个原因是你工作的环境。 如果您已经在使用企业库的一部分，那可能足以推动您使用企业库日志logging。
如果您在Silverlight中开发，该怎么办？ 你可能会select使用像Clog这样的东西- 钙的一部分 。 您也可以select使用与Silverlight和WP7兼容的NLog 2.0。
System.Diagnostics插件（Ukadc.Diagnostics，Essential.Diagnostics）。 这些不是日志框架本身。 而是代表可用于现有System.Diagnostics框架的有用对象和扩展点的集合。 在我看来，最好的东西之一就是每个插件都增加了格式化日志输出的function，类似于如何使用log4net和NLog格式化它。 我没有使用Essential.Diagnostics，但我已经尝试了Ukadc.Diagnostics，并认为它非常酷。 编写自己的“格式化令牌”甚至是很容易的。
我不知道这是否完全回答了你的问题（反正这个问题相当广泛），但我认为这里有很多值得思考的地方。
我刚刚开始在VS2010中使用log4net，发现它依赖于System.Web …这使得它与“.NET xx客户端configuration文件”框架目标不兼容…考虑到这里有人发布了Windows Update使用客户端configuration文件作为可选的.NET可再发行组件，这意味着如果您想让代码在大多数机器上运行，log4net不再是您所select的logging器。
感谢其他选项的信息 – 我会检查出来…
只需要添加一些从微软Build 2013会议中学到的东西：
-
重负荷下的Log4NET写入文件主要是因为这个过程是同步的。 在某些情况下可能会争用和超时。 这可以使用AppDynamics或任何其他类似的工具进行validation。
-
NLog没有在负载情况下实现排队，IO调用堆栈起来。
-
据微软称，ETW使用高效的内核环形缓冲区。 .NET 4.5和事件日志框架与语义logging应用程序块（AKA SLAB）结合在一起将使这个效率更高。
我不是log4j或log4net的粉丝。 我喜欢java.util.net日志工具，所以我已经在https://github.com/greggwon/NetLog/上重新创build了名为NetLog的github项目。; 随意提供反馈意见。 我想花一些时间来在基于ConfigurationManager的configuration在一个logging.properties文件的liu。 使用java.util.logging，使用命令行属性设置来指定日志configuration所在的位置总是很容易。 如果不使用ConfigurationManager，使用.net会更痛苦。 为CM提供支持，将为logging器和处理程序之间的某些不同关系打开大门，这可能会使某些事情变得更好。
NetLog包含一个将login到系统事件日志的EventLogHandler。 它也有一个Level.EventLog级别设置在“警告”下面，这将允许你有一个命名“级别”的目标的事件日志，而不使用“警告”或“严重”。 我也有一个TCPSocketHandler，它可以让你远程login到“日志logging”，这样你就可以在窗口上有一个“尾巴”，没有“尾巴”程序可用。
看看GitHub上的NetLog.Logging包，这是我的创build。 它有一个监控应用程序，并遵循java.util.logging API范例，因为这是我喜欢使用的。 它有一个自旋锁，用于访问“写入”，锁持有者在继续之前写入排队的所有logging，达到极限。 这将允许日志减less基于I / O的争用，并提供良好的折衷。
出于某种原因，System.Diagnostics不支持将所有跟踪输出定向到单个侦听器的方式。 如果要将多个源定向到相同的侦听器，则必须按名称明确列出每个源。
在一个有很多依赖的大系统中，你可能不知道所有的来源，你可能不关心。 你只是希望输出看看下面发生了什么。 不得不为每个源单独设置监听器，这使得在大型系统中使用System.Diagnostics非常困难。
log4net不仅支持根级别appender（listener），还支持分级日志logging，允许您将一组逻辑源的日志loggingconfiguration为一个组。 在我看来，这使得log4net成为明智的select。
