355

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.

Greg Dean
  • 29,221
  • 14
  • 67
  • 78
  • 9
    This is the logger that I use: System.IO.File.AppendAllText(@"c:\log.txt", string.Format("{0}\r\n", message)); – zumalifeguard Aug 31 '10 at 19:41
  • 213
    Good for you, but some people may need the ability to turn logging on/off dynamically, to use different log levels, to automatically delete old log data, etc. – Tor Hovland Oct 12 '10 at 13:01
  • 23
    It should be noted that the Log4Net documentation is terrible. – BentOnCoding Mar 16 '12 at 15:04
  • 2
    You should give ReflectInsight a try. Much more powerful then both http://insightextensions.codeplex.com/ – code5 Sep 16 '13 at 17:39
  • @code5 ReflectInsight viewer is commercial (free until March 2014), $299 after 2013-Jul-01. – yzorg Oct 09 '13 at 19:59

15 Answers15

383

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.

Pat
  • 16,515
  • 15
  • 95
  • 114
Matt
  • 4,388
  • 1
  • 15
  • 8
  • 19
    +1 on recommending building a Facade for true Seperation of Concerns (SoC), or so you don't polute your domain. – eduncan911 Jan 26 '10 at 22:43
  • 66
    The facade only works if you can do it without breaking diagnostic values that are dependent on the call stack, etc. I've seen a lot of facades that break these essential diagnostic features that ended up doing more harm that good... – James Schek Feb 10 '10 at 22:58
  • Have you looked back at EntLib now that you have more experience with logging? I'm new to logging platforms and want to make sure I go with the most solid solution first if possible. – Jeff LaFay Jun 01 '10 at 18:23
  • This project was postponed, so I have no new knowledge, sorry. Our new architect is sponsoring EntLib to replace our persistence, so it will probably be our logger, too. In your case - I don't know your situ or what you need when you say "solid". All 3 are sufficient for basic corporate .NET apps. They more differentiate on ease of setup, ease of use, flat-out performance, options, and sellability. EntLib will make a fine solution if you don't mind the syntax. IMO, coming up with your logging strategy/policy will be the bigger deal. – Matt Jun 03 '10 at 03:10
  • 11
    Log4Net does not yet support the Client Profiles of .NET 3.5 SP1 and .NET 4, because it references System.Web. Just wanted to point that out, although it's actually closely related to 'with a dependency on Log4Net, use Log4Net.' – Simon D. Jun 12 '10 at 07:47
  • 59
    NLog is actively supported (http://nlog-project.org/download) while Log4Net hasn't been updated since version 1.2.10 was published published April 19, 2006 (https://issues.apache.org/jira/browse/LOG4NET/fixforversion/11128) – Jay Cincotta Sep 23 '10 at 21:35
  • 1
    Log4Net gets confused with IPv4 and IPv6 on newer Windows machines. Can't resolve localhost properly. Several unofficial patches are floating around. See for example http://devva.net/blog/post/log4net-UdpAppender-on-IPv6-(Windows-2008-Vista-or-7).aspx – Tormod Hystad Jan 13 '11 at 10:31
  • 5
    If you have a dependency on a library using log4net and want to use NLog instead (or vice-versa), it's fairly straightforward to write and configure a custom Appender class to bridge the two. – dbkk Jun 16 '11 at 21:48
  • 4
    I wanted to add that Log4Net was recently updated to 1.2.11, and now adds support for .NET 4.0 as well as the client profiles of .NET 3.5 and .NET 4.0. – Nick Silberstein Oct 26 '11 at 17:28
  • 2
    I noticed RavenDB uses Nlog. Ayenede isn't renowned for choosing bad code & frameworks. Remeber Nhibernate has been around a long time & (probably) predates Nlog. Also if you're using Raven then obviously Nlog is already there. If you're planning on using Raven then get some Nlog practice in. Without being too sheeplish about it I'm inclined to follow Ayende's lead on pretty-much anything .NET related. – CAD bloke Feb 16 '12 at 23:14
  • Could you explain in a little more detail why using a 'facade' is useful? What is a 'logging facade' anyway? – Ciaran Gallagher Nov 27 '13 at 10:41
  • 3
    @CiaranGallagher - Sorry, I don't watch this question much anymore. Your comment would be a great question for discussion elsewhere! For me, at the time, the "facade" would have been a) to streamline EntLib's verbose method calls and b) so we could switch out loggers without changing code all across the app. The latter was a concern for due to frequent technical leadership turnover and associated changes in our tech stack direction. FWIW, I would have made a very simple, ~4 function custom interface and not have used the logging interface libraries Pat recommended (not to diss them). – Matt Apr 29 '14 at 15:06
  • 1
    You can use System.Diagnostics.Trace.TraceError(...) in bundle with NLog.NLogTraceListener. This will give you flexibility and power of logger library. Helpful when you ship some component to a customer that uses other logger. – Stanislav Berkov Sep 10 '14 at 10:22
158

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
Jay Cincotta
  • 4,298
  • 3
  • 21
  • 17
  • 30
    But does it need updating? If it ain't broken, don't fix it? – glenneroo Nov 19 '10 at 01:27
  • 24
    It *is* broken: * Messes up ip address resolution between IPv4/IPv6 for localhost on Vista and Win7 (several unofficial patches are floating around) * Doesn't compile in .Net 4.0 Client Profile – Tormod Hystad Jan 13 '11 at 10:28
  • 1
    Yes, it needs updating. It requires you to write code to extend AdoNetAppender to use a connection name already configured, vs hardcoding the string. This has been a long requested feature. The thing is stable, but considered dead until we see evidence of life. – codenheim Mar 29 '11 at 20:06
  • 6
    There appears to be a .NET 4.0 version in the works for Log4Net. – scope_creep Apr 10 '11 at 15:17
  • NLog Beta 2 doesn't work on mono and .Net 3.5 (http://nlog.codeplex.com/workitem/5305 reported on Oct 15 2010) – o3o Jul 18 '11 at 18:50
  • NLog 2 was released a month ago with this support, and log4net still has the issue. I also can't find any info on when log4net 1.2.11 is going to be released (which will support .Net 4.0). Edit: Seems like they still don't have a timeline, though it is getting closer: http://mail-archives.apache.org/mod_mbox/logging-log4net-user/201108.mbox/%3C8739gynifc.fsf@v35516.1blu.de%3E – Merlyn Morgan-Graham Aug 22 '11 at 20:16
  • 38
    [log4net has launched v1.2.11 on October 2011](https://issues.apache.org/jira/browse/LOG4NET). I think this answer is obsolete now. – Mariano Desanze Oct 25 '11 at 20:30
  • 83
    Actually, this answer was still valuable to me. I'm in the process of choosing a logger, and this answer tells us that log4net has been updated once in the last half decade, while NLog is a more active project. – John Reynolds Nov 08 '11 at 20:00
  • 3
    Since NLog 2.0 has been released nothing happens with it too. Their web site indicates they are actively seeking someone to take over the whole project. So I guess you can't really call NLog being "more active". – Alexey Zimarev Aug 14 '12 at 09:49
  • log4net has 103 issues (5 critical, 56 major): https://issues.apache.org/jira/browse/LOG4NET#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel – Chris S Jul 11 '13 at 15:40
  • 1
    For fun, Google Trends still thinks log4net is in the lead -- http://www.google.ca/trends/explore#q=log4net%2C%20%20NLog&cmpt=q – yoyo Aug 15 '13 at 17:50
  • 1
    Probably fairer to link to the log4net [changelog](https://issues.apache.org/jira/browse/LOG4NET/?selectedTab=com.atlassian.jira.jira-projects-plugin:changelog-panel), rather than a particular release. There have been 3 releases since 1.2.10, with 1.2.13 just over a year ago. – fakeleft Dec 31 '14 at 19:20
97

Having had an experience with both frameworks recently, I thought I can share my views on each frameworks.

I was asked to evaluate the logging frameworks for an existing web application, I narrowed down my choices to NLog (v2.0) and log4net (v1.2.11) after going through various online forums. Here are my findings:

  1. Setting/starting up with NLog is dead easy. You go through the Getting started tutorial on their website and you are done. You get a fair idea, how thing might be with nlog. Config file is so intuitive that anyone can understand the config. For example: if you want to set the internal logging on, you set the flag in Nlog config file's header node, which is where you would expect it to be. In log4net, you set different flags in web.config's appSettings section.

  2. In log4net, internal logging doesnt output timestamp which is annoying. In Nlog, you get a nice log with timestamps. I found it very useful in my evaluations.

  3. Filters in log4net - You better check my this question - log4net filter - how to write AND filter to ignore log messages and if you find an answer/solution for this, please let me know. I understand, there is a workaround for this question, as you can write your own custom filter. But something which is not easily available in log4net.

  4. Performance - I logged around 3000 log messages to database using a stored procedure. I used simple for loop (int i=0; i<3000; i++... to log the same message 3000 times. For the writes: log4net AdoAppender took almost double the time than NLog.

  5. Log4net doesnt support asynchronous appender.

It was sufficient comparison for me to choose NLog as the logging framework. :)

Community
  • 1
  • 1
Narayan Akhade
  • 2,694
  • 3
  • 21
  • 30
  • log4net's internal debugging logs: http://logging.apache.org/log4net/release/sdk/log4net.Util.LogLog.InternalDebugging.html – Narayan Akhade Aug 04 '12 at 07:10
36

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.

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

Jeremy
  • 481
  • 4
  • 5
34

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

Brian Mains
  • 50,520
  • 35
  • 148
  • 257
Florian Doyon
  • 4,146
  • 1
  • 27
  • 37
25

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/

Ray Hayes
  • 14,896
  • 8
  • 53
  • 78
Chris Brandsma
  • 11,666
  • 5
  • 47
  • 58
  • 9
    @greg: Note that in NHibernate v3 the dependency on log4net is thankfully removed - it's pluggable so you can use NLog if you wish. – UpTheCreek May 16 '11 at 09:41
  • NLog is an equal pain to configure/figure out what's wrong too. At least with log4net you can find documentation and or google for issues. – Mrchief May 20 '13 at 03:33
  • Good point on taking the rest of your stack into consideration, I cannot say that is a concern I would have considered off the top of my head. While it looks like NHibernate is no longer an example for this scenario, Sitecore provides a contemporary example of this, since it uses Log4Net internally. Sitecore is pretty extensible, so you could use whatever you prefer to log, but that is far more complex than editing the site's web.config to add your own loggers – Scott Simontis Apr 09 '15 at 18:15
16

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

Joe
  • 161
  • 1
  • 2
14

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();
Francis Shanahan
  • 2,043
  • 19
  • 21
13

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

Lorenzo
  • 29,081
  • 49
  • 125
  • 222
  • 1
    Looking at that matrix it seems considerably out of date with respect to at least The Object Guy's framework, which is a commercial competitor. – Andy Dent Jul 09 '11 at 08:19
9

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.

Vitaliy Ulantikov
  • 10,157
  • 3
  • 61
  • 54
  • 22
    Add to your fileappender config to prevent this (mentioned on the log4net examples page here: http://logging.apache.org/log4net/release/config-examples.html) – EventHorizon Jun 18 '10 at 13:47
9

Shameless plug for an open source project I run, but given the lively discussion about which .NET logging framework is more active I thought I'd post an obligatory link to Serilog.

To use within an application, Serilog is similar to (and draws heavily on) log4net. Unlike other .NET logging options, however, Serilog is about preserving the structure of log events for offline analysis. When you write:

Log.Information("The answer is {Answer}", 42);

Most logging libraries immediately render the message into a string. Serilog can do that too, but it preserves the { Answer: 42 } property so that later on, using one of a number of NoSQL data stores, you can properly query events based on the value of Answer.

We're close to a 1.0 and support all of the modern (.NET 4.5, Windows Store and Windows Phone 8) platforms.

Nicholas Blumhardt
  • 30,271
  • 4
  • 90
  • 101
  • But the question is: Does it support Mono? ;) It looks promising (and I love the thread and needle logo) but couldn't find any information on whether it supports Mono or not. – ashokgelal Mar 06 '14 at 08:41
  • Good question :) ... yes, we have users on Mono - I'm not sure if they're using the .NET 4.5 or 4.0 build of Serilog, but if you hit any issues we'll help out. – Nicholas Blumhardt Mar 12 '14 at 05:00
  • .NET 4.5 support got me, downloading and trying out your solution right now – Fat Shogun Jun 13 '14 at 12:40
8

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

Pat
  • 16,515
  • 15
  • 95
  • 114
eddycharly
  • 81
  • 1
  • 1
4

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

Gabe
  • 84,912
  • 12
  • 139
  • 238
Rashack
  • 4,667
  • 2
  • 26
  • 35
2

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

tsimon
  • 8,362
  • 2
  • 30
  • 41
0

Based on my experience, SmartInspect beats both NLog and log4net.

Its extremely easy to use, documentation is great, and you can view and filter previously logged messages with their interactive log viewer, which is a huge real world advantage.

One thing I like is the tabbed views of data, like the browser tabs in Chrome. Each tab can provide a different filtered view of the log.

Contango
  • 76,540
  • 58
  • 260
  • 305