log4net vs. Nlog

I was recently tasked to "prototype up some loggin'" for an upcoming project. I didn't have any logging framework experience. I researched, ran through tutorials, made toy apps, etc. on Log4Net, NLog, and Enterprise Library for a few days. Came back 3-4 weeks later and put them together into a cohesive demo. Hopefully some of this is useful to you.

My recommendation for our project is this:

1. Use a logging facade (e.g. Common.Logging, SimpleLoggingFacade) to avoid direct dependencies.
2. If we end up using Enterprise Library for other facilities, then use it for Logging, too.
3. If we end up using something with a dependency on Log4Net, use Log4Net.
4. If none of the above, use NLog. Which I'd prefer.

That's based on these findings (opinions!):

• All 3 frameworks are capable and can do some sophisticated things. We want a quality solution, but frankly don't need ultra high performance or 60 types of event sinks.
• All 3 have very similar basic concepts.
• Each has its own cool tricks, like really advanced routing, or dynamic log filenames, file truncating, etc.
• All 3 are pretty well documented in their own way.
• For a complete newb like me, they were all a little awkward initially. No drastic differences here for the basics. I got over it.
• When revisiting things a few weeks later, NLog was clearly the easiest to resume. I needed very little brush up on it. With Log4Net, I had to revisit a few online examples to get going. With EntLib, I gave up and did the tutorials all over again from scratch - I was totally lost.
• I couldn't figure out how to get EntLib to do some things like log to the database. It might be easy, but it was beyond my time limit.
• Log4Net and NLog have a small in-code footprint. EntLib is spammy, but I'd use a facade over it anyway.
• I accidentally mis-configured EntLib and it told me at run time. Log4Net didn't. I didn't have an accidental mis-config with NLog.
• EntLib comes with a nice looking app.config editor, which you 100% need. NLog has a config file schema so you get "intellisense". Log4Net comes with nada.

So obviously I like NLog so far. Not enough to use it in spite of having another solution available, though.

First look at the rest of your stack.

If you are using NHibernate, it utilizes Log4Net directly. Other frameworks might have other specific loggers they need.

Other than that: both work fine.

I've settled on Log4Net myself. It can be a pain to configure, and if it isn't configured correctly it is a pain to figure out what went wrong. But you can make it do almost anything you would want from a logger.

If you don't have a standing issue with Log4Net, here is an article I wrote on how to get started with it: http://elegantcode.com/2007/12/07/getting-started-with-log4net/

I second NLog too because it works with unmanaged code too. I suppose it could be possibe to use log4net and log4cxx together, but NLog handles both managed and unmanaged code out of the box.

I also looked at Common.Logging, a facade that makes abstraction of the logging api, it supports log4net, NLog and Entreprise Library. I don't think i'll use it, but i like how they use lambdas to improve performance when logging is disabled (a feature shared with NLog and probably others).

You might also consider Microsoft Enterprise Library Logging Block. It comes with nice designer.

I think the general consensus is that nlog is a bit easier to configure and use. Both are quite capable, though.