log4net vs. Nlog

Question

Anyone have experience for both? How do they stack up against each other?

We are planning on using one of them for logging in an enterprise application.

References:

log4net

nlog

EDIT: We have no existing dependencies to either nlog or log4net.

Answer 1

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/

Answer 2

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

Answer 3

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

Answer 4

I have the same question, but I choice the NHibernate, so my first choice is log4net, just beginning.

I notice the NLog seem simplier than log4net, i wander what is the continue ?

Answer 5

As I noticed, log4net locks their output files the whole time application is running, so you can't delete them. Otherwise they are similar.

So I prefer NLog.

Answer 6

For us, the key difference is in overall perf...

Have a look at Logger.IsDebugEnabled in NLog versus Log4Net, from our tests, NLog has less overhead and that's what we are after (low-latency stuff).

Cheers, Florian

Answer 7

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 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.

Answer 8

I echo the above and do prefer nLog. Entlib is needlessly bloated.

Re:Log4net One thing that ALWAYS gets me with log4net is forgetting to add the following to the global.asax to init the component:

log4net.Config.XmlConfigurator.Configure();

Answer 9

For anyone getting to this thread late, you may want to take a look back at the .Net Base Class Library (BCL). Many people missed the changes between .Net 1.1 and .Net 2.0 when the TraceSource class was introduced (circa 2005).

Using the TraceSource is analagous to other logging frameworks, with granular control of logging, configuration in app.config/web.config, and programmatic access - without the overhead of the enterprise application block.

• .Net BCL Team Blog: Intro to Tracing - Part I (Look at Part II a,b,c as well)

There are also a number of comparisons floating around: "log4net vs TraceSource"

Answer 10

If you go here you can find a comprehensive matrix that includes both the NLog and Log4Net libs as well as Enterprise Lib and other products.

Somebody could argue that the matrix is done in a way to underline the features of the only commercial lib present in the matrix. I think it's true but it was useful anyway to drive my choice versus NLog.

Regards

Answer 11

A key consideration that hasn't been much discussed is support and updates.

Log4Net hasn't been updated since version 1.2.10 was published April 19, 2006.

In contrast, NLog has been actively supported since 2006 will soon release NLog 2.0 supporting many platforms that didn't exist when log4net was last updated such as:

• NET Framework 2.0 SP1 and above, 3.5 & 4.0 (Client and Extended profiles)
• Silverlight 2.0, 3.0, 4.0
• .NET Compact Framework 2.0, 3.5
• Mono 2.x profile

Answer 12

Well .. I used Enterprise library for database logging tasks and now I switched to NLog due to performance bottleneck.

some comparison info :

http://pauliusraila.blogspot.com/2010/10/solving-database-logging-bottlenecks.html