问题
EDIT: Common.Logging 2.1.1 was released on June 9, 2012 and the Github page is fairly active, with the author commenting specifically on the health of the project.
We're looking at using Common.Logging in a new .NET project but I'm a bit concerned that the project seems to have become inactive. The homepage was last updated in 2009 and the latest version available on SourceForge was created in 2010. I've already found an incompatibility with NLog 2 and I'm concerned that this may become a bigger problem over time. I have noticed that Enterprise Library 5.0 isn't listed as being compatible but I've not tried it.
Are there any other alternatives that provide a similar common interface?
回答1:
I have been using Common.Logging for four years, and I'm able to use it with NLog2. To answer your question thoroughly, we need to take a closer look at Common.Logging first. Common.Logging gives you two benefits:
Since 1.x, Common.Logging let you write your application independent of the logging framework. So you can easily change from one logging framework to another without even recompiling your application. This is particular useful to the development of common library, which may be used by various applications that use different logging frameworks.
Starting 2.x, Common.Logging let you aggregate the logging information from various logging frameworks. Let's say we are developing an application and want to leverage two 3rd part libraries, say A3rd.dll and B3rd.dll. A3rd.dll uses log4net, but B3rd.dll uses NLog. Now how do you consolidate the log information from A3rd.dll and B3rd.dll into one log file (or log monitoring system)? Common.Logging can help, for example, it can capture the log message from NLog and send it over to log4net, and then let log4net to write it to the log file or send it to anywhere that log4net can do.
Now, back to NLog2. The logging API in NLog2 is backward compatible with NLog1, but the API for configuration and targeting were changed. So if all you need is to send the log message to NLog2, you can simply do assembly redirect (see my answer here: Can NLog v2 be used with Common.Logging).
That being said, if you want to aggregate NLog2 message to other logging framework using Common.Logging, the assembly redirect approach won't work. A NLog2 specific adapter has to be created.
Like @Kugel said, inactive could mean stable and mature. As Common.Logging works with various logging framework, it is unlikely to release a new version every time one of the supported logging framework makes a release. It could be otherwise more confusion than help. Hence, assembly redirect should always be considered first. Only when there is really an incompatibility issue arise, like I mentioned about the NLog2 message redirecting, send an email to the mailing list and I'm sure somebody will jump in and help.
Cheers, Kenneth
回答2:
It looks like there's something going on in this area of the bclcontrib-abstract project:
http://code.google.com/p/bclcontrib-abstract/source/browse/Contoso.Abstract.NLog/Abstract/NLogServiceLog.cs
Having tried the BclContrib-Abstract.NLog 0.1.5 NuGet package I'm not liking the way that it sits under the Contoso namespace (Contoso.Abstract.NLog).
回答3:
if I want to use an unsupported library (e.g. NLog2) it looks like one option would be to implement a custom FactoryAdapter. I'm not sure how difficult this would be, but it could be an option:
If you want to plug in a new, yet unsupported logging library, you need to provide a logger factory adapter that implementes the Common.Logging.ILoggerFactoryAdapter interface. Loggers must implement the Common.Logging.ILog interface.
Source: http://netcommon.sourceforge.net/docs/2.0.0/reference/html/ch01.html#logging-advanced-customfactoryadapter
Update:
Here is my first attempt at an implementation for NLog 2, use at your own risk. Any comments welcome:
https://gist.github.com/1107148
来源：https://stackoverflow.com/questions/6778233/are-there-any-alternatives-to-common-logging