Yes, but....

Be cautious about log4net's versioning.  Every OSS tool in the known .Net world seems to have a dependency on a different version of log4net and there's a breaking change in their public API at some point.  I ripped the support out of StructureMap because of the versioning conflicts with NAnt/NHibernate/etc.

I got into soooo much trouble one time as a consultant when I mentioned to a client's staff that I thought log4net was easier to use than the MS EIF framework.  Not a good idea to disagree with the centralized architecture team at a big company.

Is there anything that ISN'T easier to use than the MS EIF framework?!! Anybody know how the latest Enterprise Library 2.0 logging compares with log4net (I believe they finally replaced EIF :)). One of the things that concerns me about log4net (aside from the versioning, the weak documentation and the breaking API changes) is the fact it's been at a 0.x beta for more than a couple of years now and not much seems to be happening. It does what it needs to very well but will it be here for the long haul or has Enterprise Library stolen its thunder by finally getting its act together?

I, personally, think the Enterprise Library 2.0 Logging Application Block rocks. It is based on TraceListeners now which makes it extremely flexible. I can't remember who, but someone did some side by side performance tests between it and log4net and performance was a wash.

The Logging Block also solves Karl's problem above of having multiple connection strings. The Logging block uses the Data Access block to log to a database - one connection string in 1 place.

Somebody has had to have created an RSS TraceListener. I'll have to look around as that sounds like a great idea.

I have a 4 part series of articles on the Logging Application Block. It is embarassingly easy to use. Look through my list of articles on EntLib here:

http://davidhayden.com/blog/dave/category/50.aspx?Show=All

or go to Part IV directly:

http://davidhayden.com/blog/dave/archive/2006/02/19/2806.aspx


Regards,

Dave

I'll throw my 2 cents in.  I just hooked up the Enterprise Library's Exception Handling Block up to my Web App... and I'm impressed.  I've been thinking about blogging about it (and I probably will).

Here's the highlights.  I used the Configuration Manager to inject the necessary options into my web config (there were a bunch).  I ended up defining an exception policy that publishes to the Logging provider of my choice and via the settings that I chose at config.  I simply make one call when an exception occurs and if it falls within the policy it gets published.  I can also defined some additional policies that will let me do something else with the exception -- like ignore it, or rethrow it as something else.  Very cool, IMO.  Anyway, I'm no expert in the Ent. Library like I think Dave is, but their code does seem to be getting better (I feel like it was good, then it became Ent. Library and it got somewhat unusable, and now it's good again).

jmiller: If you want to put logging into an application during development but are unsure as to what the final logging package will be, you could implement your own LogManager and ILog (Company.Project.Logging.LogManager and Company.Project.Logging.ILog) and code against those. ILog would contain the normal Debug, Info, Warn, etc. while LogManager would have GetLogger(string), GetLogger(Type), and an Implementation property (think abstract factory pattern) that you could plug in an implementation at run-time. Your Company.Project.Logging namespace could provide some simple built-in implementations for basic things like ConsoleLogger, DebugLogger, TraceLogger, etc. Projects like IBatisNet, Sooda, and the Castle Project all have support for pluggable logging architectures. This allows Log4Net, NLog, and/or MS EIF to be used without having to build against any one of them. This is also means you're not building against any particular version of your logging library. On my dev machine I use log4net. If the dev support people want to use MS EIF or log everything to the Event Log on the production boxes thats fine with me.

Ian Smith: Weak documentation?! Log4Net has some of the best documented code I've ever seen. _Everything_ is documented and commented:

http://logging.apache.org/log4net/release/sdk/index.html

What breaking changes? I don't think the Debug(object, Exception), Debug(object) style methods have changed signatures in several years. A vote for the 1.2.10 release is taking place now on the dev list.

I'm not much of a blogger so I'm not familiar with the RSS spec. If you think this (or any other features) would be useful feature I encourage you to subscribe to one of the log4net lists or submit a feature request for it.

Ron Grabowski
LogNet Developer

If you are using .NET 2.0, definitely check out the Enterprise Library 2.0 January release. They've completely reworked it to take advantage of all the new functionality in the 2.0 Framework. It has become a more lightweight wrapper around .NET Framework, rather than the heavy framework it once was. My favorite part is that it no longer *requires* that everything be configured in your config file - everything can be programmatically configured.
On the other hand, since it is just a wrapper around (new) existing functionality, it is also a lot less necessary. For a medium to small application, you can realistically get away with just using the classes in System.Diagnostics directly (or with a very lightweight Logger custom class).  Don't use the old static methods on the Trace class - use the new TraceSource class instead.
Check out this tracing primer for a quick overview:
http://blogs.msdn.com/bclteam/archive/2005/03/15/396431.aspx

One of the CB'ers mentioned how much he likes log4net, and I just had to 2nd that notion.  Thanks...

Hi Ron,

It's about 9 months since we decided to move from a two-three year old version of log4net to the most recent version. I was surprised to see it STILL in beta (and nine months on it appears to still be at the same beta version). We had to change quite a lot of the code (I see jmiller also refers to the API changes, so it's not just me!). It's working great for us but at a recent review several of our leads said they found the documentation poor and that new developers had trouble getting into it. Looking at the web site the conclusions that can be drawn are as follows:
- There's been no Development Roadmap for a long, long time. That page really needs updating
- There appears to have been no work done on the project for quite some time
- There is no mention of .NET 2.0 support where Enterprise Library jumped on board that wagon very very quickly and got community feedback even as the beta's were being shipped
- It's still in beta several years after it was first released.

Bottom line: Would you want to trust your production application to software that appears to be somewhat stagnant and never ready for "RTM" release?

Personally I'm glad that I took on code that already had the required structure in place and didn't have to start from scratch with the documentation that was there. There's some good "getting started" material (from memory) but I seem to remember that whenever I had a difficult question it wasn't covered (although the FAQ was a great help). I guess this documentation criticism isn't so much a criticism of log4net as the whole agile "We don't need no stinking documentation, we've got a Wiki" approach, which I've never liked for software that is extremely important to the day-to-day running of an application.

We're still getting a bunch of warnings about using obsolete interfaces (which we just haven't got around to fixing) so more changes to our code are needed to fit with the latest release, and then of course there was the switch to needing to put one of the assemblies in the GAC which hadn't been there in prior releases. No BIG deal I guess - just extra work in wanting to move forward to a bug fixed release. All that being said, I'm more than happy with the way the software's working. I guess our main issue is concerns about its long term future given the seeming inactivity and lack of any mention of .NET 2.0 on the software pre-reqs page. Contrast that with the statements that have been made about Enterprise Library and the very visible community on that and it's not hard to see why we're looking at switching.

I know the current version of Enterprise Library supports 2.0, but does it also support all of these:

Microsoft .NET Framework 1.0 (1.0.3705)
Microsoft .NET Framework 1.1 (1.1.4322)
Microsoft .NET Compact Framework 1.0 (1.0.5000)
Mono 1.0
Microsoft Shared Source CLI 1.0
CLI 1.0 Compatible

log4net supports (and has supported) the 2.0 framework for quite some time. Remember that not everyone has made the switch to 2.0 yet. I'll be lucky if my company decides to start developing applications on .NET 2.0 before the end of the year. Not everyone has the luxury of adopting new technology as soon as it is released.

Whenever someone asks the question "does log4net support .NET 2.0" on the mailing lists the replies are always "yes, I dropped it in without any problems".

The 1.2.10 release will be a non-beta release. There were 24 commits to the log4net repository in the month of March. While that's not the best way to measure activity...it does show that the code base is being developed.

I'm really not exagerating when I said everything is documented. I spent the last couple minutes trying to find a method or property that wasn't documented. I couldn't find one. In Release mode, the log4net.dll is
266,240 bytes. The log4net.xml documentation file is 1,365,390 bytes. The size of the documentation file alone is bigger than some applications!

Look at this page:

http://tinyurl.com/e3nd3 http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html

That's a lot of stuff! Can you point me to some projects with what you consider to have good/better documentation?

If your teammates need help with log4net have them read the documentation and join the mailing lists! If you think log4net doesn't do something well join the log4net list so it can be dicussed and improved.

The one thing that has always kept me away from the Enterprise Library is all the config files and assemblies. ***Disclaimer: I have a bias towards log4net***. To setup log4net, all I need is one 270k .DLL and about three lines of code:

FileAppender fileAppender = new FileAppender();
fileAppender.Layout = new PatternLayout();
log4net.Config.BasicConfigurator.Configure(fileAppender);

I personally think something that simple should be reduced to one line (I think NLog can still do it in one line!)

Here are some of my lingering questions about the Enterprise Library:

How many assemblies do I need to setup basic logging? Do I need to bring in the configuration block assemblies to setup logging?

Does it support asynchronous targets? Can I asynchronous log to a database, file, email, etc. Can I wrap an existing target with an async wrapper and have that target automatically log asynchronously?

Can I setup the config file to be an external .config file and change the logging configuration of my application without recycling it?

Can I write filters to pre-process log messages before they are logged...i.e. write a filter that rejects a log message if I've already seen the same exception from the same logger X amount of times in the last X seconds?

If so, can I chain the filters together?

Does EL have somewhat of a unified XML format when rendering messages to XML? Do you know if anyone has written something that stores log entries in the log4j XML schema?

Is there a there a .NET GUI for viewing real-time log messages sent over the network? Something along the lines of log4j's Chainsaw progam:

http://logging.apache.org/log4j/docs/chainsaw.html

I assume EL has an overload to accpet a String.Formatted message. Does it through an exception if you give it a malformed String.Format format string (i.e. you specify {0}{1} but you only pass in a value for {0})?

Will EL throw exceptions while my application is running?

Does EL give you file locking options when you're writing to a file? Can I specify if I want the file locked while the application is running or if I want to open and close the file on each write?

Am I able to configure the layout of my log messages. If I don't like the built in layout patterns (in log4net-speak it would be things like %message, %level, %newline) am I able to write my own and make those available via the config file:

%level - %officeLocation - %message%newline

Where %officeLocation is a pattern I made myself (which may accept optional parameters: %officeLocation{xyz})

Can I do fun things like set my threshold for messages coming from  certain namespace to a high threshold like ERROR then when an error occurs have the last 250 messages of all thresholds (DEBUG, TRACE, etc.) be written out along with the ERROR message? This way I could setup my application to not waste time recording a lot of messages except when something bad happens...then dump all the recent DEBUG, TRACE, etc. messages that lead up to the ERROR.

Can I create my own logging levels; i.e. create a level called DANGER  that falls between WARN and ERROR?

Do the EL developers subscribe to a forum or mailing list? Could you post the address please.

Are people able to download nightly builds of EL or do we have to wait until a specific version is released? About how often are updates released. Anything is faster than log4net releases ;-)

Does EL support things like fallback/rollover targets? If my database temporarily goes down can I write to a backup location then redirect messages to the database once its back online?

Based on your knowledge of EL, what do you think it does better/different than log4net?

- Ron

I have been using log4net .. forever it seems. It is just amazingly flexable and the performance is THERE. I used it on the 30th and 60th busiest sites on the net. It just works. We were able to add global logging to a centralized database for all applicatios - by just implementing an appender for our needs - small task.

My 1 concern - as someone said above - "beta"!? what does that mean!! I have really used it - rock solid for years! DITCH THE BETA-NESS!

-Chris

I have heard about log4net but never used it till now. I am a big fan of the enterprise library 2.0 but I decided to go with log4net for logging in the open source project I run because of its powerful simplicity.  Both libraries are really good logging blocks but I found log4net meets my needs better for this project.

I also don't like the multiple connection strings but I found this blog about some tips when using log4net in a web environment which shows  how to set the connection string in code by retreiving the existing connection string from the web.config.

http://weblogs.asp.net/dr.netjes/archive/2005/02/16/374780.aspx

You can use Chainsaw to receive events from log4net over the network.  log4net provides an xml formatter conforming to log4j's dtd, which you can use with log4net's UDPappender (configure Chainsaw to use a UDPReceiver).

Chainsaw can also read regular text log files (configure Chainsaw to use a LogFilePatternReceiver).

Dear karl, I need to know is there any feature available in Enterprice Application block 2.0 (Logging) like the feature of RollingFileAppender available in Log4Net. if yest tell me the detail, I am so confused after reading these kind of comparision articles.

I've looked at log4net, system.diagnostics, and enterprise library, and I agree with many of the comments that entlib is pretty heavy in terms of the configuration and assembly footprint.

That's okay if you're creating a service or web application - but becomes a problem if you're looking at how to log from a class library that will be used in a variety of places. The decision to reference any portion of the enterprise library (or log4net for that matter) from a class library means you're writing a check the application must cash. That is to say you're obligating the application hosting of your component to also include the correct version of the logging libraries. The problem becomes totally unmanageable if the application then needs to use more than one component that have decided to use different logging libraries, or were even compiled with different builds of the same logging library.

For logging from class libraries I would say always use the tracesource from system.diagnostics in dotnet2. That way you are not imposing on the hosting process in any way - it's guaranteed to be available and you'll simply be silent if your logger is not configured.

The System.Diagnostics.TraceListener model also gives you a perfect mechanism for directing the logging output where you need it. It comes with some basic outputers, and there's an example of one that outputs to the asp.net page trace sytem. It would be very easy for the application to have a tracelistener that directs the system.diagnostics from various sources to log4net or the application block, and the key there is it's the host application that's entirely in control of that.

So - log4net was very nice in dotnet<2.0 because it addressed a very real need, but there's a native solution for that need in 2.0 now in system.diagnostics that's strikingly similar. Almost identical in many ways. Once your company moves to 2.0 it's time to stop using either log4net or entlib at the trace source end of the equation. And like someone earlier pointed out for simple applications the existing trace listeners in system.diagnostics are perfectly useful.

TDDing Log4net