Welcome to Ukadc.Diagnostics

Latest Updates

15 June 2010 - Josh Twist
1 July 2009 - Josh Twist
25 June 2009 - Josh Twist
19 June 2008 - Josh Twist
25 April 2008 - Josh Twist
17 April 2008 - Josh Twist
10 April 2008 - Josh Twist
8 April 2008 - Josh Twist
24 March 2008 - Josh Twist

Project Description

The idea behind this project was to provide a framework that uses the inbuilt features of the System.Diagnostics namespace, and show how logging and tracing can be integrated into a client application whilst taking advantage of the services exposed by System.Diagnostics. There are many logging/tracing frameworks already available for .NET, however the .NET framework uses the services of System.Diagnostics and this project will utilise these inbuilt features and extend these where necessary.

This project was created by Josh Twist and Morgan Skinner who both work for Microsoft's Application Development Consulting (ADC) team in the UK.

The project's primary goals are:
Before jumping in it's worthwhile reading the following primer article on logging in .NET - this provides plenty of background information on logging in .NET. Also, be sure to check out the FAQ below.

Features

Click the links for more information

Listeners
Filters
Common - useful stuff to know when using the Ukadc.Diagnostics libraries
Extended API

A Logging Primer

The facilities of System.Diagnostics are not well understood by everyone - indeed if you have been developing since .NET 1.0 you would be forgiven for never having gone back to this namespace as the support for logging in .NET 1.0 was, to be fair, limited.

As a brief overview, consider the following image.

Tracing.png

A TraceSource is supplied by your application. Each trace source has one or more TraceListeners - these are where the traced data goes. In the image we have a SqlListener - presumably logging events to a database, and a cryptically named A.N.Other listener, meaning you can create your own.

Each listener (in standard .NET) can have at most one TraceFilter - a trace filter can further refine which events get logged, so you could for example selectively log events based on which source raised the event, the severity of the event, or a host of other criteria. As an added bonus of using the Ukadc.Diagnostics framework, we've implemented a chap called the MultiFilter which allows you to add multiple trace filters, and combine them in a form of 'decision tree'.

All of this is built upon the premise that you should use the standard capabilities of .NET to log your trace events. To understand what's in the box with .NET 2.0 (and above) click on the link below.

Logging Primer

FAQ

Q: When will the project release?
A: We hope the project will continually evolve - but the first CTP should be complete around the end of April 2008.

Q: Is it OK to use the library now?
A: Sure - I'd consider the current state an early CTP (certainly pre-Beta) so don't be surprised if you find a bug or we make a little breaking change or two. If you do start to use Ukadc.Diagnostics please be sure to feedback (either via the issues tab on codeplex or directly to josh at hisblog. Watch this space or Josh's blog for announcements.

Q: Does this project compete with Enterprise Library logging, log4net or nlog?
A: That certainly isn't our motivation but obviously we do hope to build something useful enough to provide an alternative. The project aims to make the best of all the work that has already gone into the System.Diagnostics namespace and adds some features you would expect to find 'as standard' in these better known logging solutions.

Q: What is the difference between Ukadc.Diagnostics and Enterprise Library's logging functionality?
A: The main difference is that you don't have to take a direct dependency on Ukadc.Diagnostics to take advantage of most of the functionality. You can code against the System.Diagnostics API and 'configure-in' the Ukadc.Diagnostics bits that you want to wire up. Both Ukadc.Diagnostics and EnterpriseLibrary logging make use of classes in the System.Diagnostics namespace. However, whilst Enterprise Library uses some of the classes offered by System.Diagnostics, it does not use the 'plumbing' provided by System.Diagnostics and implements its own framework for logging and own logging sources. As such, some features supported by System.Diagnostics are not supported (such as filters at the listener level). Ukadc.Diagnostics aims to simply extend System.Diagnostics and therefore all the core functionality will remain intact. Of course, this means certain features available with EnterpriseLibrary logging (such as Categories, Environments and the configuration UI) are not directly supported by Ukadc.Diagnostics. In fact, you can actually use Ukadc.Diagnostics with Enterprise Library: watch this series to see how to do this http://www.thejoyofcode.com/Introducing_Ukadc_Diagnostics.aspx.

Q: Why use it?
A: Various features in .NET use System.Diagnostics for their output, and using this yourself will allow you to better integrate logs from disparate sources. As an example, WCF includes some great logging capabilities such that it is possible to trace a request from client to server (and everything in between), and correlate these logs together with your own client code logs and your own server logs. This gives you a complete end-to-end logging strategy. Also, you don't have to take a direct dependency (no Add Reference) on Ukadc.Diagnostics to take advantage of most of the functionality. You can just configure it all in.