您可以通过更一般的谷歌搜索在 StackOverflow 上找到有关 log4net 和 NLog 的大量信息。
您还可以找到很多关于 System.Diagnostics 的信息。关于 System.Diagnostics 需要注意的一件事,我认为您会在 StackOverflow 上找到很多关于使用 Debug.Write/WriteLine 和 Trace.Write/WriteLine 的参考资料。一个可以说是“更好”的方法是使用 TraceSources。TraceSources 类似于 log4net 和 NLog 中的记录器。TraceSources 允许您对日志消息具有更高程度的粒度,从而更容易打开和关闭一些日志(按类或类别,除了按级别)。TraceSources 确实有一个缺点,与 log4net 和 NLog 相比,您在代码中创建的每个 TraceSource 都必须在 app.config 中显式配置(如果您希望它实际记录)。
log4net 和 NLog 有一个分层概念,如果您要求的确切记录器未明确配置,则检查其“祖先”以查看是否配置了任何“祖先”,如果是,则请求的记录器“继承”这些设置。祖先只是记录器名称中由“.”分隔的部分。(因此,如果您请求一个名为 的记录器"ABC.DEF.GHI"
,则祖先将是"ABC.DEF"
,并且"ABC"
)。也可能(需要?)在 app.config 中有一个“根”记录器配置,如果没有显式配置并且没有配置祖先,所有记录器请求都将退回到该配置。因此,您可以仅配置一个“根”记录器以在某个级别进行记录,并且您代码中的所有记录器都将在该级别记录。或者,您可以将“根”记录器配置为“关闭”,然后显式打开一个或多个记录器(或通过配置祖先)。这样,除了那些配置的记录器之外,没有记录器会记录。
如果你看这里,你会发现一个有趣的 System.Diagnostics TraceSources 包装器,它提供了与 log4net 和 NLog 非常相似的继承能力。
为了显示:
log4net 和 NLog 中记录器的常见使用模式是获取这样的记录器:
//log4net
static ILog logger = LogManager.GetLogger(
System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
//NLog
static Logger logger = LogManager.GetCurrentClassLogger();
在这两种情况下,记录器的名称都是完全限定的类型名称。
在 app.config 文件中,如果需要,您可以只配置“根”记录器,两个记录器都将继承根记录器的设置(级别、附加程序/目标等)。或者,您可以为某些命名空间配置记录器。在该命名空间中定义其类型的任何记录器都将继承这些记录器设置。
够了 log4net 和 NLog,你可能已经知道它们是如何工作的。
上面的链接说明了一个基于 TraceSource 的包装器,它允许类似的配置。所以,如果你愿意,你可以在你的课堂上做这样的事情:
static TraceSource ts = new TraceSource(
System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
使用上面链接的包装器,您可以在更高级别(类/命名空间层次结构,而不是级别)配置 TraceSource 并在较低级别的记录器中继承这些设置。
因此,如果您的完全限定类型名称是这样的:ABC.DEF.GHI,那么您可以为 ABC 或 ABC.DEF(命名空间级别)配置 TraceSource,并且类“GHI”将继承这些设置。这确实可以减少您必须执行的配置量。
请注意,您不限于(使用任何这些日志记录平台)使用类的类型或类型名称来获取记录器。您可以定义自己的记录器命名方案,可能基于功能区域(“Communication”、“Communication.Send”、“Communication.Receive”等)。同样,您可以请求最高粒度(或不)的 logger/TraceSource,然后以任何有意义的粒度级别进行配置。
因此,您可以像这样在代码中请求记录器:
ILog logger = LogManager.GetLogger("Communication.Receive");
ILog logger = LogManager.GetLogger("Communication.Send");
Logger logger = LogManager.GetLogger("Communication.Receive");
Logger logger = LogManager.GetLogger("Communication.Send");
TraceSource ts = new TraceSource("Communication.Receive");
TraceSource ts = new TraceSource("Communication.Send");
如果您在 app.config 文件中仅配置“通信”,那么所有记录器都将继承这些设置(因为它们是“通信”的后代)。如果您只配置“Communication.Receive”,那么只有“Communication.Receive”记录器会记录。“Communication.Send”记录器将被禁用。如果同时配置“Communication”和“Commuincation.Receive”,则“Communication.Receive”记录器将记录在“Communication.Receive”设置中,而“Communication.Sender”记录器将记录在“Communication”设置中。在 log4net 和 NLog 中,继承可能不止这些,但我对它的了解还不够。
使用 System.Diagnostics 时您会错过的一件事是非常轻松地格式化日志输出格式的灵活性。有一个第三方库为基于 TraceSource 的日志记录提供了非常好的可配置格式。你可以在这里找到它。
我用过Common.Logging一些。主要用于原型设计,但我可能会在我们的下一个项目中使用它。它工作得很好,编写自己的日志抽象来插入它相对容易(例如,如果你想编写一个类似于我上面链接的 TraceSource 抽象)。Common.Logging 现在缺少两个重要的东西(尽管他们的网站说他们计划在“下一个”版本中发布)是日志记录上下文(如 log4net 和 NLog NDC/MDC/GDC 对象和 System.Diagnostics.CorrelationManger.LogicalOperationStack ) 和 Silverlight 兼容性。在使用 Common.Logging 时,您仍然可以与代码中的 log4net 或 NLog 上下文对象进行交互,但这违背了它的目的,不是吗。
我不知道我有没有帮助!
以下是关于 log4net、NLog 和 TraceSource 的一些要点:
log4net - 非常流行,可能需要一些更新 - 至少建立在 .NET 4.0 上,几年前的最后一个版本,非常灵活。
NLog - 在许多方面与 log4net 非常相似,现在是新版本(NLog 2.0 的测试版刚刚发布)
TraceSource - 没有第三方依赖,无需您(或某人)的一些努力,不如 log4net 或 NLog 强大(关键缺陷 - 记录器层次结构,输出格式 - 两者都可以通过上面的链接轻松解决),微软检测了他们的许多组件使用 System.Diagnostics,这样您就可以获得 Microsoft 的日志输出和交错的日志输出。(通常,在其他日志系统中捕获 System.Diagnostics 很容易,因此可能不是大问题)。
虽然我没有经常使用 log4net 或 NLog,但在两者之间我会倾向于 NLog,主要是因为刚刚发布的新版本(测试版)。我认为 TraceSource 也是一个合理的选择,如果更基本的话,特别是如果您实现记录器层次结构并使用上面链接的 Ukadc.Diagnostics 库。
或者,使用 Common.Logging,您可以避免或延迟为您的底层日志平台做出决定,直到您准备好。无论如何,Common.Logging 的一个非常有用的方面是,您可以在开发产品时“试驾”日志平台,而无需更改任何应用程序代码。您不必等到决定使用特定的日志记录平台才能将日志记录添加到您的代码中。现在通过 Common.Logging api 添加它。当您接近交付时,您应该缩小您的日志平台选择范围。使用该平台交付(如果您重新分发日志平台),您就完成了。如果您愿意,您仍然可以稍后更改。