Logging App Block vs System.Diagnostics.Trace

Topics: Logging Application Block
Mar 5, 2007 at 2:32 PM
Hi all

I am looking at recommending the Logging Application Block for my project, and am comparing it against the .NET native System.Diagnostics Trace and Debug feature, based on my project's scope. While I am trying the good hands-on tutorials provided, I was wondering if someone could point me to any such comparisons done earlier (like a differential feature list or improvements), or any caveats in using System.Diagnostics, to help me make the right decision. Appreciate any feedback on this.

Mar 5, 2007 at 3:03 PM
Hi Subbu -

As you've probably seen, the Logging Application Block is built on top of the same TraceListener class used by System.Diagnostics, but we've added a number of new capabilities on top, including:
  • Strongly-typed log entry classes
  • Formatting log entries to strings via templates
  • Filtering by categories, priorities etc
  • Routing to different collections of Trace Listeners via categories
  • Timed activities
  • Larger collection of TraceListeners, including WMI, MSMQ, Database and e-mail

Of course if you don't need these things, using Trace/Debug directly will be more lightweight.

Mar 6, 2007 at 12:58 PM
Thanks Tom, that was precisely what I was searching for.
Mar 6, 2007 at 4:03 PM
Does the Logging Application Block make any use of trace sources?
Mar 6, 2007 at 4:24 PM
No. We used the TraceSource class earlier on in development, but we discovered some reliability problems resulting from the way we were using this class. In the end we replaced it with our own LogSource class which works in much the same way as TraceSource but avoided the issue we were seeing.

Jul 6, 2007 at 12:29 AM
Hey Tom. Would you mind elaborating on the issues you ran into with using the TraceSource class?
Nov 2, 2007 at 3:20 PM
Hi Tom,

We are examing the same issue. It would be really helpfull if would get some details about the issue.
Nov 3, 2007 at 12:53 AM
I'm not sure Tom is monitoring this thread, but in an email I received from him in response to this same question he indicated there were issues related to attempting to log before the trace source had fully initialized which resulted in some lost logging messages. I would still be interested in hearing a more detailed explanation of the problem however. It would seem that if they experienced some problem with invoking the TraceSource after instantiating a new instance then there must be some inherent problem with the native .Net tracing API itself that would be nice to be aware of. While I'm an advocate of using the Logging Application Block for applications, I prefer to use the native tracing API when writing reusable infrastructure code since it has less dependencies, ensures portability, and ensures there will be no conflicts with potentially differing versions of the Logging Application Block.

If possible, I'd like to see the P&P team figure out a way to go back to using the TraceSource as the foundational type for logging. It would be nice to be able to configure listeners using the standard configuration methodology or through the block's configuration, and I think there might be some cool techniques this would enable (e.g. using dependency injection to inject a TraceSource created directly , or through the Logging Application Block).