QuickLog is an EXTREMELY basic implementation of a logging API. Easy to extend by implementation of an event but sufficient to use by itself for some needs. It’s own API can be used directly or all calls to System.Trace.Write(…) will also be directed to the current output log file. The log does not roll until the application is restarted at which time the old log is renamed to ‘.bak’ to maintain one historical log.
The implementation is very primitive relying entirely upon the system trace routines. It basically creates a default log file and adds a TextWriterTraceLister to append to the file. All API calls essentially just call the Trace.Write() api.
Q: So why use this and not just directly use Trace.Write?
A1: Well for one if you litter your code with calls to the System.Diagnostics namespace your stuck with it. By using QuickLog you can alway migrate to another logging implementation when the need arises. BTW, it’s API is roughly equivelent to the Logging project on this site.
A2: Additionally calling Trace.Write requires you to also litter your code with String.Format() calls. This may not seem like a bad idea until one generates an exception. This basically changes your logging system into a liability instead of a debugging aid.
A3: If that isn’t enough, Trace.Write has a performance penalty associated with it, especially if a process is monitoring debug messages. It is possible for another process to deadlock your process while waiting on a call from the underlying Win32 api OutputDebugString() to return. This lock is caused by the implementation details of these debug messages and the global named mutex they rely upon.
Based on the above comments, the need for an isolation between your code an a log api is clear. Write one yourself or use this quick and dirty implementation as a starting point, but use something.
For usage review the test case, you can find the code here:
http://csharptest.net/browse/src/Shared/QuickLog.cs