System.Diagnostics.Debug namespace vs Other logging solutions (log4net, MS Enterprise Library, etc.)

Question

I\'m currently investigating various logging possibilities for .net projects and I can\'t decide between System.Diagnostics.Debug/Trace features and third party libraries like l

Answer 1

I know this is old, but System.Diagnostics.Trace is pretty easy to configure if you keep it simple. I've been using the simple text writer config block for years, copied right out of the MSDN docs.

No one mentions this very often, but in your code, you can use the built-in Trace.TraceInformation, Trace.TraceWarning, and Trace.TraceError to easily segregate 3 levels of trace output and then in the config file choose which level to output (see config below). If you choose Information in the config's "EventTypeFilter", you get all 3 in your output. If you choose Error, you'll only get TraceError messages in your output. Most of the time, I just leave mine on Error, so if something does happen in my application, I'll already have that output in my trace file. Inside my Catch blocks, I'll add TraceError code to output useful info. TraceInformation is good for outputting things like timing or spots in code which you've passed through, and dumping variable values along the way. TraceWarning is good for things which are handleable, but not desirable - like maybe a web service is taking a long time to complete, or the number of data records returned exceeds a threshold that might cause future issues.

There is a small downside, in that all these lines of trace code still execute regardless of compile level. If they are set to not output, that should reduce the overhead quite a bit. But if you're writing high-performance code, you may want to wrap those lines in conditional compile markers.