A Few Notes on the Logging Application Block

We are switching a project I’m working on from a custom logging solution to the one built into the Enterprise Library, the "Logging Application Block". This is nice, because it means we can get rid of quite a bit of custom code (that’s code we no longer have to debug or maintain). The logging application block is very well done as far as I can tell thus far. It makes it very easy to configure logging without having to change code.

Because we do have a particular way of logging that doesn’t fit exactly into what the app block does, I did have to create a custom trace listener. But even with that I was able to remove several hundred lines of unnecessary code.

I think there are really three main advantages for going this route. First, the logging is completely configuration file based, and in the app.config. This is excellent, because QA and our deployment team to change the logging for debugging’s sake without having to have development mess with it.

Second, when you use a solution like this you have a much better chance of pulling off consistency across groups. If everyone is using the same logging solution, then everyone knows what to expect and what to do when they need to deal with any aspect of logging.

Third, as it was said above, it requires less code. Granted, it is probable that the enterprise library team did not write the application blocks without defects. There may be some bugs in the logging application block. But I can guarantee that their code was more extensively tested than our internal code. I trust it quite a bit more.

A temptation that we programmers can easily fall into is the desire to over-architect and write code we don’t really need to write. I have that same temptation. I like programming. I like flexing my programming muscles. And sure, we all program extraneous things to learn more about our craft. That’s very important. But as professionals, we need to think about what needs to be created, not necessarily what we want to create. We’re lucky when those are the same. But when they are not, we shouldn’t pretend that they are.

Now, a little nitty-gritty. There are a few important sections in the configuration of the logging application block. <listeners /> is the section where you define what listeners you want to use, whether that is a built in listener like the file or event log listener, or a custom listener. These are the things that "listen" for logging requests, and log appropriately.

The <formatters /> section is a little more boring, but can be useful for formatting the log messages.

The use of the <specialSources /> section is not immediately obvious, and took a little digging, and this posting was helpful. Essentially, the listeners listed here are used when the typical logging fails, and something needs to be logged about that.

The most important section is the <categorySources /> section. That is where you route different categories of log messages to different sources. For example, you can log "information" log requests to the event log, and "errors" to a database log. You can route things to email, a message queue, a text file, or a custom trace listener. If you want to go the custom route, you can maybe send an instant message or an sms message.

It is the last bit that I find most useful. Because it is configuration file based, anybody can change what goes to where anytime they want to, and no code needs to be touched. What a good idea that was...

If you want more information, I recommend reading the documentation and checking out this series of posts. That link is to part 4 in a 4-part series since it is only the last part that has links to all the other parts in the series.