Are there any alternatives to Common.Logging? [closed]

Question

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?

Photocopy

Inactive may mean its stable and mature. – Bacchanalia

@Bacchanalia Yes, though it needs a certain amount of activity when it's designed to interact with other libraries that have a more active release schedule. – Photocopy

I'm keen to know if there are any alternatives too. The devs seem to be too busy, going by the last few posts on their mailing list which is a shame as common.logging is used in quite a few places. Having said that they did push out a nuget package very recently. – Marya

SimpleLoggingFacade (SLF) is an alternative: slf.codeplex.com – Secondclass

You should give ReflectInsight a try. It supports all the extensions that Common.Logging supports plus Common.Logging itself. insightextensions.codeplex.com DISCLAIMER: I'm one of the developers for ReflectInsight. – Mohamed

@Secondclass SLF seems to be way older - Wed Dec 2, 2009 at 10:00 AM – Waikiki

Answer 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:

1. 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.

2. 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

Airspeed

Thanks very useful stuff, especially the assembly redirect. I still think that if the Common.Logging team want to make people use their project that a few updates to the website at least might be good - for example documenting the assembly redirect. Just because the code is stable and not changing, it doesn't mean the website should be static too. – Photocopy

Answer 2

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

Photocopy

I have managed to implement this and am hoping to make it available soon. – Photocopy

Answer 3

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).

Photocopy