Home > View Post

What's next for Ukadc.Diagnostics?

It's about time we did some more work on Ukadc.Diagnostics (if you're new to this blog and have no idea what I'm talking about check out this introductory post). However we need your input to decide what to do next.


There's a bunch of new TraceListeners that we'd like to add to the existing Sql, Smtp, ODS and InMemory ones in the current version. Here's an overview of some we have in mind:
  • FileListener - pretty self explanatory. Allows you to write log entries to a file and once again you can use Ukadc.Diagnostics' system of tokens to format the output. My current thinking on this is that the file path could also be specified by tokens. This would give you 'rolling' functionality by using a file path such as "{Year}-{Month}-{Day}.log" which would automatically roll on a daily basis. Perhaps you want a separate file per process id: "log({ProcessId}).txt". Perhaps you have all your server farm's log files writing to the same UNC share but want a seperate file per machine? Easy: "{MachineName}_{Year}-{Month}-{Day}.log".

  • CsvFileListener - very similar to the above but with the ability to specify columns (similar to parameters in the SqlTraceListener) and tokens to create well-formed delimited files.

  • EventLogListener - a listener that writes to the Event Log much like the EventLogTraceListener that ships OOB with System.Diagnostics but this one would use Ukadc.Diagnostics' system of tokens.

  • XmlTraceListener - not 100% sure how this would work yet but the idea would be to create an Xml file using Ukadc.Diagnostics' system of tokens. Suggestions on a postcard.

  • WmiTraceListener - TraceListener that uses WMI to publish events.

  • MsmqTraceListener - The asynchronous listener. Allows the events to dropped into an MSMQ queue so that they are processed asynchronously. The events are then picked up out of the queue by another process and written to the appropriate selection of trace listeners.

  • ServiceBrokerTraceListener - as per the MSMQ trace listener but using SQL Server's Service Broker functionality instead of MSMQ.


Please choose the listener you'd most like to see added:

If you can't see the poll - please go here: The Survey. It's tiny and will only take a second, promise!

Josh Post By Josh Twist
12:43 AM
20 Jun 2008

» Next Post: How to remove a file attribute in PowerShell
« Previous Post: Determining row and column of a grid click

Comments are closed for this post.

Posted by Steve Culshaw @ 29 Sep 2008 5:13 AM
All sound interesting, but any news on them?

Posted by Marty Bell @ 29 Mar 2009 3:06 PM
The main concern with logging data out of band i.e. to a looging database or service is the latency in the distributed nature of that solution with the high volume of data generated by this function....

Have you done any thinking around a possible store & forward pattern for this scenario to a) reduce the number of hops to the logging store b) ease the impact on the source application?

Interested in what your thoughts are....for example for we starting to over-engineer a fairly well understood pattern?



© 2005 - 2021 Josh Twist - All Rights Reserved.