Introducing Ukadc.Diagnostics

  • Article

"Great logging, terrible name"

Long time readers of this blog are probably aware that I'm a big fan of logging and instrumentation. The keen eyed of you may have even spotted the subject of this post in my recent post Xaml for config. The clue was the name of the System.Diagnostics TraceListener: "Ukadc.Diagnostics.Listeners.InMemoryTraceListener". What's that all about then?

Ukadc.Diagnostics is a library of extensions for .NET's System.Diagnostics that I'm working on with some colleagues from Microsoft's UK Application Development Consulting (UKADC) team. The project was born out of a conversation with Morgan Skinner when I mentioned that I tended to use log4net, nlog or Enterprise Library logging over the stuff that ships out of the box (OOB) with .NET 2+. He wanted to know why and this was roughly what I replied:

  • There isn't enough OOB - for example no database support, no email support and just two filters
  • Lack of configurability of output (i.e. little or no control over what and how data is written by the listeners)
  • You can only have one filter per listener (no complex routing)
  • It isn't easy enough to extend [1]
  • The API is confusing when compared to the competition

However, as Morgan noted, there are some redeeming features, including

  • No need to take a dependency on an external library - it's available right away without thinking about it
  • No concrete dependency on Open Source - not a problem for many, but a blocker for others

And so, Ukadc.Diagnostics was born. It's currently hosted on codeplex at www.codeplex.com/UkadcDiagnostics. In summary, we're aiming to bridge some of the gaps between System.Diagnostics and those great alternatives I mentioned earlier.

Over the course of the next few posts I'll be introducing this project, how it works and what it can do but first, let's get a few FAQ's out of the way.

Q. Is this a replacement for Enterprise Library logging (EntLib) or intended to compete with EntLib, log4net or nlog?
A. Abolutely not. EntLib is much more than just a logging framework. I think these are all great projects and if you're happy using them I suggest you stick with them. However, I imagine Ukadc.Diagnostics will have two main audiences; people who:

  • don't do much or any logging at the moment
  • refuse to take a direct dependency on entlib/log4net/nlog for whatever reason

Of course, we do hope to create something useful and performant enough that it's a realistic alternative. In fact, as you'll see in an upcoming post, you can even use this stuff *with* EntLib's logging functionality.

Q. When will the project be complete??
A. I hope it will continually evolve but I'm considering the current state an early CTP and, based on getting plenty of community feedback (yes, that means you!) hopefully we'll get to a beta very quickly. So get involved, let us know what's right and what's wrong.

I'll maintain this post as an index to the subsequent posts, so here's what's coming:

  1. From zero to logging with System.Diagnostics
  2. Using tokens in Ukadc.Diagnostics to control output
  3. Creating your own tokens
  4. Using the SQL Trace Listener
  5. Using the SQL Trace Listener with Enterprise Library logging
  6. Using the Ukadc.Diagnostics with existing TraceSources
  7. and more...

[1]: In the April '06 edition of MSDN Magazine Krzysztof Cwalina wrote: "Custom trace listeners can be implemented by inheriting from the TraceListener class directly. But for historical reasons, this is not very easy. TraceListener contains many interdependent virtual members that can be overridden. And after working with these APIs for several years, I still forget which members need to be overridden in which scenarios." (From Extending System.Diagnostics).

Originally posted by Josh Twist on 25th of April 2008 here.