Trace Listeners vs. Custom Logging Component

[Jeremy S.]

I'm writing several small utility apps that all need to do some routine
logging of their progress, exceptions encountered, etc. The utilities
include a couple of Console apps, a windows Service, and a couple of Windows
Forms apps.

I was just considering the possibility of implementing the logging
capability via the built-in Trace listeners, rather than writing my own
logging component.

Practically all of the documentation on Trace and Debug classes talks about
using those classes for troubleshooting purposes. But it appears that there
is no reason they can't be used for routine logging purposes.

What would you do and why?... would you prefer to roll your own reusable
logging component or use the Trace and TraceListeners?

Thanks.

 

[Nicholas Paldino [.NET/C# MVP]]

Jeremy,

I would use the trace listeners. The trace listeners allow for the
abstraction of the storage mechanism from the actual mechanism which
captures the trace. While the examples usually output to the console, there
is no reason you can not have it write to a file, a database, or any other
storage mechanism that you wish.

If you aren't going to use the trace mechanism, at least use a component
that does the work for you. log4net, for example, is a popular logging
library that is pretty extensible, from what I understand.

 

[Jon Skeet [C# MVP]]

On Sep 19, 3:51 pm, "Nicholas Paldino [.NET/C# MVP]"

If you aren't going to use the trace mechanism, at least use a component
that does the work for you. log4net, for example, is a popular logging
library that is pretty extensible, from what I understand.

Indeed it is. I'd go for log4net - being able to log specific
categories (rather than just severities) is incredibly useful.

Jon

 

[Arnshea]

I'm writing several small utility apps that all need to do some routine
logging of their progress, exceptions encountered, etc. The utilities
include a couple of Console apps, a windows Service, and a couple of Windows
Forms apps.

I was just considering the possibility of implementing the logging
capability via the built-in Trace listeners, rather than writing my own
logging component.

Practically all of the documentation on Trace and Debug classes talks about
using those classes for troubleshooting purposes. But it appears that there
is no reason they can't be used for routine logging purposes.

What would you do and why?... would you prefer to roll your own reusable
logging component or use the Trace and TraceListeners?

Thanks.

I like using the built in trace listeners and trace switches. Being
able to add a listener, add a switch or change the level of tracing
via config file (and/or programmatically) is very helpful. I've found
the built-in levels (off, error, warning, info, verbose) more than
adequate.

The only major downside to the built in tracing functionality I've run
into is lack of built-in logrolling. Not a huge problem if you're
tracing to the windows event log. Also, it's easy enough to derive
your own trace listener and add rolling.

I tend to prefer using built in framework functionality wherever
possible. Sometimes you can't; it may not be mature enough, it may
require too much of a departure from existing use, or maybe there
isn't enough time to learn to use it.

No big deal, I've heard good things about log4net and other loggers.
Still, IMHO once something good enough comes from The Source (MSFT) my
personal preference is to use it til it can't be used anymore