Alois Kraus

blog

  Home  |   Contact  |   Syndication    |   Login
  133 Posts | 8 Stories | 368 Comments | 162 Trackbacks

News



Archives

Post Categories

Programming

 This time I wanted to write something about the .NET Framework that is solved not optimal of the .NET Framework. My unsuspecting victim is the well known System.Diagnostics.Trace class. Static classes have the big plus that they are easy to use but they can be very hard to maintain if you want to extend it (no derivation) and have a lifetime problem with the objects that are created inside it. The Trace facade is in my opinion a prominent example of  how you should not design a reliable static facade class. It's has many features that are nice but it's at the same time a fine example of design that has lost its vision. It tries to do too many things at the same time without succeeding in the optimal solution for all the goals it might have. Tracing should be fast, right? The .NET Trace definitely not the fastest solution. Yes it's flexible and can be very good configured inside your App.config file. But if you have used the Microsoft Logging Application Block of Enterprise Library 2.0 once then you know how much farther design for flexibility can be done. But I must admit that the Entlib TraceListeners does derive from the .NET ones. Below is a +- table about the .NET Trace regarding Performance Reliability and Extensibility.
In the following article I will show you what reliability issues there are and how to solve them.

Performance Reliability Extensibility/
Ease of use
TraceSwitches allow to configure at run  time what  should be traced.


- DefaultTraceListener  uses OutputDebugString  which  is by far the slowest method to trace.


 
- I loose traces if I do not call Trace.Close/Flush from time to time.

- Static Trace.Close is a mistake because I cannot really close something that is static.

- A Trace.Write after a Trace.Close causes loss of all following traces in case of file based listeners.

(+ Some Listeners do reopen itself after being closed. The File Listener can do this if you init it with a file name)
Dynamic Trace Switch Configuration

+ Dynamic Trace Listener Configuration

- Other (Logging) solutions are far more flexible.

- It is nearly impossible to write a program that does  capture all traces even during application shutdown.

The most obvious reliability problem I did find is demonstrated with a very simple Console Application:

Show More ...

posted on Monday, June 12, 2006 9:18 PM