Common Logging 2.0 for .NET Released

Last week I released a new version of Common Logging 2.0 for the .NET platform. You can get the distribution as well as online API and User Reference documentation from the project website. For users of previous versions there is also a section about upgrading to 2.0.

What is Common.Logging?

Similar to Java's Apache commons-logging, Common.Logging is an ultra-thin brigde between different .NET logging implementations based on original work done by the iBatis.NET team. A framework or library using Common.Logging can be used with any logging implementation at runtime and thus doesn't lock a user to a specific framework or worse letting him struggle with different frameworks using different logging implementations.


Common.Logging comes with adapters for all popular logging implementations like log4net and Enterprise Library Logging.

Bridging between logging implementations

You might run into the problem, that libraries used by your application use different logging implementations. Common.Logging allows you to route from those implementations into any logging system of your choice:


Please see reference documentation for an example on how to configure such a bridging scenario.

What's new in 2.0?

Several extensions and improvements were made, namly

  • Dropped .NET 1.1 Support
  • Added support for Enterprise Library 4.1 Logging
  • Extended and improved ILog Interface
  • Convenience LogManager.GetCurrentClassLogger() Method
  • Bi-directional log event routing between logging implementations (see bridging above)
  • Improved performance

I already blogged about comparing Common.Logging performance to System.Diagnostics.Trace. According to a thread on stackoverflow, log4net seems even slower than System.Diagnostics.Trace.

Configuring Common.Logging

For examples on how to configure and use Common.Logging and bridge different logging implementations, please see the user refererence guide. The API documentation contains configuration and usage examples on each adapter implementation. Here is an example for configuring Common.Logging to write messages to the console:

 <sectionGroup name="common">
   <section name="logging"
            type="Common.Logging.ConfigurationSectionHandler, Common.Logging"
            requirePermission="false" />
   <factoryAdapter type="Common.Logging.Simple.ConsoleOutLoggerFactoryAdapter, Common.Logging">
     <arg key="level" value="ALL" />

Using Common.Logging

Using Common.Logging is as simple as shown below:

ILog log = LogManager.GetCurrentClassLogger();
log.DebugFormat("Hi {0}", "dude");

Hint: When using NET 3.5, you can leverage lambda syntax for logging to avoid any performance penalties:

log.Debug( m=>m("value= {0}", obj.ExpensiveToCalculateInformation()) );

This is the equivalent to writing

if (log.IsDebugEnabled)
 log.Debug("value={0}", obj.ExpensiveToCalculateInformation());

and ensures that you don't have to pay for calculating the debug information message in case level "Debug" is disabled.

Further Roadmap

The following features and improvements are planned for the next release, some of them already in the works:

Of course I would like to invite you to submit any feature request, bug reports or other improvement suggestions to the project's issue tracker.

Happy logging!


Anonymous said...

Thanks for this release! I hope opensource projects like NHibernate and others will switch to the Commonlogging approach at some time.

tobsen said...
This comment has been removed by the author.
tobsen said...

Even better! I just read "Bridging between logging systems" (http://netcommon.sourceforge.net/docs/2.0.0/api/html/index.html), this is exactly what I was looking for!

Erich Eichinger said...


glad u like it!

in case you would like to see Common.Logging in your favorite framework, spread the news and let the makers of those frameworks know!

Anonymous said...

I'm seeing some problems opening the project in Visual Studio 2008 SP1, it seems that the paths for the testing frameworks are too long. It opens correctly when I move the project to the root of my drive, but I do not want to keep my projects there. I prefer to keep my projects in the standard My Documents\Visual Studio 2008\Projects folder. Is there any way to release an update that will fix this problem?

Erich Eichinger said...

@Erik: sure there is - it is just a matter of time that I am currently seriously lacking. Helping hands are absolutely welcome!

Zuleika said...

hi Eric,

thank for your blog. Hope you still maintain this blog. I am trying to download Common.Logging v2.0.0 in the sourceforge website that you suggest. But it appears when i tried to uncompress the zip file it was corrupted. I tried to download and uncompress older version and it works. Do you have any idea other website that i can download ? currently i need that component for my .NET development. Thanks in advance for your help

Anonymous said...

@Zuleika, I successfully downloaded it via:
This should also work for you.

Zuleika said...

@blog : Thank you for your reply, i tried to download from the link that you have provided and same error happened when i want to uncompress it using Windows-built zip extractor("The Compressed (zipped) Folder is invalid or corrupted"). But then i tried to use another software called 7-zip for uncompress the .zip files and gladly it works :). Anyway thanks for your help

Erich Eichinger said...

it seems I used a WinZip version for zipping things up, that produces an incompatible .zip format by default. I will upload a re-zipped version this weekend. Sorry for the inconvenience!

Unknown said...

Learned a lot of new things from your post!Good creation ,It's amazing blog

.Net Online Training