log4net versus TraceSource [closed]

Question

In this thread many people have indicated that they use log4net. I am a fan of TraceSources and would like to know why log4net is used.

Here is why I like trace sources:

• Pluggable listeners - XML, TextFile, Console, EventLog, roll your own
• Customisable trace switches (error, warning, info, verbose, start, end, custom)
• Customisable configuration
• The Logging Application Block is just a big set of TraceListeners
• Correlation of activities/scopes (e.g., associate all logs within an ASP.NET request with a given customer
• The Service Trace Viewer allows you to visualize events against these activities individually
• All of it is configurable in app.config/web.config.

Since the .NET framework internally uses TraceSources, it also gives me a consistent way of configuring tracing - with log4net, I have to configure log4net as well as TraceSources.

What does log4net give me that TraceSources don't (or that couldn't be done by writing a couple of custom TraceListeners)?

Answer 1

In the very early days (.NET 1.0) tracing in the .NET Framework was pretty limited.

For example TraceSource partitioning didn't come until .NET 2.0 and you only had four levels (Error, Warning, Information, Verbose), although you could use half a dozen boolean switches for partitioning if you wanted.

log4j is popular in Java and so got a lot of support for a .NET port, and once it became popular it kind of stayed that way, even though people don't even use it properly (e.g. wrapping it in a singleton logger and losing it's main feature).

Still, I think that log4net and other frameworks (e.g. NLog, Common.Logging, and even EntLib) went the wrong way by implementing their own logging system from the ground up, i.e. changing even the way you write log statements in the first place.

I would have much preferred to see effort, especially since .NET 2.0, put into extending the solid basis of what is already in .NET. For a project that does extend what is already there, have a look at the Essential Diagnostics project on CodePlex (http://essentialdiagnostics.codeplex.com/).

Some strengths of log4net:

• It is similar to log4j, if you run a mixed environment and want consistent logging.

• Automatic logger hierarchy that inherits settings is quite neat, compared to how many trace sources you implement and have to configure each. (although probably overkill in some cases).

• log4net already has around 28 appenders (equivalent to trace listeners), whereas System.Diagnostics only has 10 (but see the Essential.Diagnostics project for more), so if you really think you may need the RemoteSyslogAppender, NetSendAppender, AnsiColorTerminalAppender or TelnetAppender, then you are in luck.

Drawbacks (compared to System.Diagnostics):

• You need to use different logging syntax, so if you are already using source.TraceEvent(), you need to go through and replace everything.

• This also extends to different syntax for correlation, so you need to change from CorrelationManager to log4net contexts.

• Doesn't easily integrate with Framework tracing (e.g. WCF).

• Poor support for Event ID's (need to use a separate extension project IEventLog).

• Doesn't yet support Event Tracing for Windows (Vista), or the Service Trace Viewer XML format.