Abstracting .NET logging with Common Infrastructure Libraries:

Question

Hi,

I've recently been considering abstracting my logging across the application. A more specific post on another resource led to the recommendation of the "Common Infrastructure Libraries":

http://netcommon.sourceforge.net/

Specifically, the Common.Logging class, which provides a common interface which can sit in front of a number of logging implimentations (such as log4net).

I'm a bit loathed to introduce yet another peice of 3rd party code into my project though.

Has anybody used this library? I would be interested in hearing your experiences.

Thanks

Answer 1

Are you going to be switching between the logging projects mentioned?

Are you distributing source to someone who might be using one of the listed logging projects, that you aren't using?

1. There are MANY more logging projects than the ones supported by Common.Logging
2. This appears to be a lot like ODBC did years ago. It's sold as being interchangeable, but as soon as you use one provider specific feature, you can no longer switch.
3. When something goes wrong in logging you now have 2 layers to debug.

Again; if you're not going to be switching libraries, I wouldn't use the Common.Logging class.

Answer 2

I've used the Common Infrastructure Library with log4net, and it worked well. I used it rather than just log4net because my client expressed the wish to keep open a possibility to use Microsoft's Enterprise Library (EntLib) logging.

I'm not sure why Brad Bruce advises against using this abstraction layer - it was a no-brainer to use and didn't cause any problems. IMO log4net is streets ahead of anything else available, but some people want EntLib just because it has the added comfort factor of the Microsoft stamp on it. By my using the abstraction layer, I give my client the freedom to switch to EntLib without code changes or recompiling - just a configuration file change.

Answer 3

As I began to utilize log4net in my MVC app I became concerned about the tight coupling of my controller classes with the concrete log4net implementation. It's true that committing to the specific interface defined in Common.Logging (which incidentally mirrors that of log4net) is just that; a commitment. But the 2.0 release of Common.Logging gave me an immediate level of abstraction, and the log4net interface it mimics is battle tested and simple to use. Also, I like the idea of being able to use, test, and experiment with different concrete logging implementations by simply adding a reference and updating a Web.config file.

All of Bruce's points are perfectly valid. The abstraction may be nothing more than a false sense of security and the decision may end up biting me in the butt. Nonetheless, sometimes you just have to err on the side of best practices until bester practices come along. :-)

Answer 4

As a quick follow up... I was on a logging kick today, and decided to try to get Chainsaw working so I could have a view of my app's logs in real-time. However, I wasn't able to get a UdpReceiver working in Chainsaw.

The solution was to forget about Chainsaw and enable NLog (via the Common.Logging config settings) and use the NLogViewer instead. NLog and NLogViewer worked together as advertised and I can now view logs as they happen. I was able to incorporate NLog into my app without modifying my code base one bit. The payoff of including the Common.Logging abstraction came much sooner than I ever would have expected.