System.Diagnostics.Debug命名空间与其他日志记录解决方案(log4net,MS Enterprise Library等)

我正在调查.net项目的各种日志记录可能性,我无法在System.Diagnostics.Debug/Trace功能和第三方库(如log4net,MS Enterprise Library,NLog等)之间做出决定.
目前我已经发现了这个:

System.Diagnostics相当难以配置和使用,因为您需要显式配置所有侦听器,过滤器,源等.它似乎也缺少对DB的批量插入(考虑每个都写入100'000个日志条目它自己的插入,恐怖,不是吗？).但是对于某些人而言,不使用额外的库来进行像Logging这样的"基本"事情被认为是"酷"(当然,在某些时候,减少项目所依赖的第三方库的数量是有意义的,但这次不是,我想)

第三方功能更强大,通常更快,更容易使用,但配置有时也会很痛苦,而且这些库通常不太可靠(比如EntLib的神秘突然停止记录等)

Common.Logging怎么样？是否值得尝试(因为,正如我所听到的,它提供了插入各种日志框架,并充当应用程序和所需的lib之间的接口)？

如果有人能指出我正确的方向或纠正(或添加一些东西)给我上面给出的比较,我将非常感激!也许如果你鼓励我使用第三方,你可以建议一些特定的一方(考虑到我们的应用程序很可能不需要任何花哨的东西,如UDP,滚动文件等 - 只是普通文件,电子邮件,数据库和事件簿)？
提前致谢!

您可以在StackOverflow上找到有关log4net和NLog的大量信息,通常是谷歌搜索.

您还可以找到有关System.Diagnostics的大量信息.关于System.Diagnostics有一点需要注意,我认为你会在StackOverflow上找到很多关于使用Debug.Write/WriteLine和Trace.Write/WriteLine的引用.可以说是"更好"的方法是使用TraceSources.TraceSources类似于log4net和NLog中的记录器.TraceSources允许您为日志消息提供更高的粒度,使得更容易打开一些登录和一些关闭(按类或类别,除了级别).与log4net和NLog相比,TraceSources有一个缺点,即必须在app.config中显式配置您在代码中创建的每个TraceSource(如果您希望它实际记录).

log4net和NLog具有分层概念,如果未明确配置您要求的确切记录器,则检查其"祖先"以查看是否配置了任何"祖先",如果是,则请求的记录器"继承"这些设置.祖先只是由"."分隔的记录器名称的部分.(所以,如果你要求一个叫做的记录器"ABC.DEF.GHI",那么祖先就是"ABC.DEF",和"ABC").在app.config中还可以(必需？)配置"root"记录器配置,如果没有显式配置并且没有配置祖先,则所有记录器请求都将回退到该配置.因此,您只能配置一个"根"记录器来记录某个级别,并且代码中的所有记录器都将记录在该级别.或者,您可以将"根"记录器配置为"关闭",然后显式打开一个或多个记录器(或通过配置祖先).通过这种方式,NO记录器将为已配置的记录器记录EXCEPT.

如果你看这里,你会发现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文件中,如果需要,您可以只配置"root"记录器,两个记录器都将继承根记录器的设置(级别,appenders/targets等).或者,您可以为某个命名空间配置记录器.在该命名空间中定义类型的任何记录器都将继承这些记录器设置.

足够的log4net和NLog,你可能已经知道它们是如何工作的.

上面的链接说明了一个基于TraceSource的包装器,它允许类似的配置.所以,如果你愿意,你可以在你的课程中做这样的事情:

static TraceSource ts = new TraceSource(
               System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

使用上面链接的包装器,您可以在更高级别(类/命名空间层次结构,而不是级别)配置TraceSource,并在较低级别的记录器中继承这些设置.

因此,如果您的完全限定类型名称是这样的:ABC.DEF.GHI,那么您可以为ABC或ABC.DEF(名称空间级别)配置TraceSource,并且类"GHI"将继承设置.这可以真正减少您必须执行的配置量.

请注意,您不限制(使用任何这些日志记录平台)使用类的类型或类型名称来获取记录器.您可以定义自己的记录器命名方案,可能基于功能区域("通信","Communication.Send","Communication.Receive"等).同样,您可以以最高程度的粒度(或不是)请求记录器/ 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文件中仅配置"通信",则所有记录器将继承这些设置(因为它们是"通信"的后代).如果仅配置"Commuincation.Receive",则只会记录"Communication.Receive"记录器."Communication.Send"记录器将被禁用.如果同时配置"通信"和"Commuincation.Receive",则"Communication.Receive"记录器将记录"Communication.Receive"设置,而"Communication.Sender"记录器将记录"通信"设置.在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也是一个合理的,如果是更基本的选择,特别是如果你实现了logger层次结构并使用上面链接的Ukadc.Diagnostics libary.

或者,使用Common.Logging,在准备好之前,您可以避免或延迟为底层日志记录平台做出决策.无论如何,Common.Logging的一个非常有用的方面是,您可以在开发产品时"试用"日志记录平台,而无需更改任何应用程序代码.您不必等到您决定在特定的日志记录平台上添加日志记录到您的代码.现在通过Common.Logging api添加它.当您接近交付时,您应该缩小您的日志记录平台选择范围.使用该平台交付(如果您重新分发日志记录平台),您就完成了.如果您愿意,您仍可以稍后更改.