Welcome to Ukadc.Diagnostics

Latest Updates

15 June 2010 - Josh Twist
1 July 2009 - Josh Twist
  • Delay in adding new features - Unfortunately, due to work commitments the project will be resting for a little while. The current source and binaries have no known significant issues and should still be good to go but we won't be adding new features until sometime next year. If you find an issue or have any questions please don't hesitate to contact us.
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
  • Quick Reference Example Available - we now have a QuickReferenceExample that should help developers quickly understand some of the Ukadc.Diagnostics features.
  • SmtpTraceListener - new TraceListener that can send E-mails via an SMTP server. See how to use it on the SmtpTraceListener page. This has caused the code coverage number to dip to 98% because we don't send an e-mail as part of the unit tests :)
8 April 2008 - Josh Twist
  • OutputDebugStringTraceListener - new TraceListener that calls OutputDebugString (similar to the DefaultTraceListener in System.Diagnostics) but allows the specification of a format string through a CombinedToken. See how to use it on the OutputDebugStringTraceListener page.
24 March 2008 - Josh Twist
  • 100% coverage - we've now achieved 100% coverage in our tests (strictly speaking its actually 99% but the last <1% is internal resources code generated by VS, so our code is totally covered).
  • SqlTraceListener added - I've finally added the SqlTraceListener and I suggest you check out the brief documentation on the SqlTraceListener page. This does create a dependency on SQLEXPRESS for one unit test but that database isn't presumed to be in any particular state (we use SMO to create the test database if isn't already there).
  • New documentation added - read about Tokens, PropertyReaders and the DynamicPropertyReader.
  • QuickStart added - a new SqlTraceListener Sample to get you going quicker.

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:
  • Extend the System.Diagnostics namespace (that has been available since the release of .NET 2.0) to support a wider range of logging requirements and narrowing the gap between other logging solutions such as log4net and nlog.
  • The library should enhance System.Diagnostics through it's numerous built-in extension points and shouldn't require any changes to existing code that uses System.Diagnostics to use some or all of the features.
  • Provide guidance as to how to use some of the features of the System.Diagnostics namespace through extension points that provide an intuitive API and a number of examples.
  • Provide classes that can be used to simplify adding in good logging code into any assembly.
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.


Click the links for more information

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.


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


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.

Last edited Jun 15, 2010 at 2:09 PM by joshtwist, version 84