Stack OverflowWhat is the best logging solution for a C# .NET 3.5 project?
[+141] [34] Odd
[2008-09-18 23:44:14]
[ c# .net .net-3.5 logging ]

My team is about to start a new enterprise wide ASP.NET development project, quite possibly the largest undertaken by my department so far and the largest project that I've ever worked on. I'm looking for a good logging solution for the system.

Firstly, what logging tools are currently available and widely used?

Secondly, for an ASP.NET (probably MVC) enterprise applicaiton, which tool is most appropriate based on your experience?

So far I've used Log4net [1] almost exclusively for all my previous projects. It's a fantastic tool, however I would like to see if there is anything I've not used out there before I start a project of this magnitude or if there is any reason I would not want to use Log4net for a project of this size.

[+122] [2008-09-19 01:53:12] Geoff

I don't see any reason not to use Log4net for a large application. It scales extremely well. Search for other questions about logging, there have been several about how much detail to log and what tools to use. Personally, I've used Log4net for projects with hundreds of classes and thousands of lines of code and never had an issue.

If you are familiar with it and it works, look no further.

(2) I use log4net and find it works well, however it is a little tiresome to set up for new projects, and if misconfigured just sits there silently rather than hinting at what might be wrong. - Richard Ev
(5) Tiresome to set up for new projects? Add a reference, add a line in Main or Global, copy-paste into app.config, that's it.... - yfeldblum
(3) @Richard E- it usually hints as to what is wrong if you have a Console window running... - RichardOD
(7) @Richard E - Given a choice between sitting silently and causing the actual application to fail, I think the log4net team made the right choice for how log4net behaves at run-time. Configuration could be easier though. - Scott A. Lawrence
(1) I used log4Net for .NET 1.1, but i don't have good experience, in-fact whenever we deploy an update it stopped working, anyway i haven't used it afterwords. I have been using Enterprise Library with DB as back end for quite a long time and it seems to be a reasonable choice - BT.
The biggest problem with Log4Net is that it is designed to run with mono .net framework verson 2.0 open source version. It needs to be upgraded to provide full support for new projects on the .net framework 4.0. NLog allows for an easier configuration for new projects and supports Silverlight, .NET Framework 4, Windows Phone 7.x - - Brian McCarthy
[+96] [2008-09-19 04:15:54] sontek

A lot of people underestimate the power of built in Debug.WriteLine and Trace.WriteLine. With those you can actually define different locations to output (that is, text file, XML, or Console.Out) and you don't have to rely on any external dependencies.

The point of Trace.WriteLine and Debug.WriteLine is to give you the ability to monitor certain areas of your code when debugging or tracing but avoid cluttering your screen or hard drive with useless output when you aren’t. When most people stumble upon Trace/Debug they think it should “Just work” – without any setup – this isn’t the case.

Another great benefits of using Trace/Debug instead of the old Console.WriteLine is you can define exactly where to log to in your application configuration or with environment variables, so sometimes you might want direct output to the console but other times you might want to log to a file.

To get your output from Trace/Debug you first need to define either DEBUG or TRACE in your preprocessor directives.

You can do this in code by placing:

#define TRACE

in your code or by defining it in Visual Studio.

After you have your preprocessor directives setup, you have to define where to log to. You can do this by defining it in your application configuration:

    <trace autoflush="false" indentsize="4">
        <add name="myListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="TextWriterOutput.log" />
        <remove name="Default" />

And then you can start your logging with System.Diagnostics.Trace.WriteLine(”Hello World”).

To learn more about Trace/Debug check out the documentation, TraceListener Class [1].


I use a text writer trace listener for debugging log4net, and it doesn't scale at all well. It will break your app once the log file grows over a few 100mb. - Simon Gibbs
(2) Note: If you build from within Visual Studio, the default Debug and Release configurations both define TRACE by default. See the project Properties editor. - gWiz
(4) 100mb log file sounds like you're replacing it for breakpoints or IIS logging @Simon - Chris S
log4net uses this facility to report errors such as broken database connections. The app was reporting bad client messages as warnings so that operations could work with the customers to fix issues. - Simon Gibbs
Looks like you can build your own TraceListener also, SQLite version would be useful for larger logs. - badbod99
Maybe not applicable for OP but Trace has one killer feature: It's built-in into .NET which means no extra dependencies. Why is dependencies a problem you might ask? Well in my workday we are asked to integate alot of external projects that use a lot of dependencies. These dependencies often conflict creating huge issues during deployment. GAC is heralded as the solution but sometimes that doesn't work because these dependencies are not strong named, or strong named the wrong way. Also GAC requires admin to install.So when people add a dependency for something that's built-in I gnash my teeth. - FuleSnabel
[+29] [2008-09-19 10:35:20] Matt Howells

You could use Common.Logging [1]. This provides a lightweight logging wrapper so that you can trivially change the underlying logging mechanism later if you need to. Since you are already familiar with log4net, I'd recommend using it as the underlying logger.


(1) you got my vote! Common.Logging rocks :-) - gef
As you just pointed it out to me, +1. - RichardOD
[+25] [2008-09-19 01:54:39] Ian P

The problem with the Enterprise Library [1] is that it's extremely bloated if you're only using logging.

I suggest using Log4net with a custom wrapper, so you're not tethered to that specific framework if you have a business need to change at a later date.


(2) Instead of a custom wrapper, consider using Common.Logging (see my answer) - Matt Howells
Surely a major benefit of Log4Net is its appender architecture, which allows you create new output destinations. That is, log4net can handle change under the API, rather than forcing a wrapper over it. - Simon Gibbs
And IMO log4net is bloated compared to Trace. - FuleSnabel
[+22] [2008-09-19 10:12:19] Graeme Bradbury

I'd recommend NLog [1]. It's as powerful as Log4net but with easier configuration. (IMO)


[+15] [2008-09-19 02:07:25] nzpcmad

If you are looking for a simple non-bloat solution (the download is only about 100K and the actual dll about 40K), I've successfully used BitFactory [1] on a number of projects.

It's small, configurable, reliable and free!


(3) Doesn't look free anymore: :( - program247365
+1 It's not free anymore, but it's really cheap :) - Mark Seemann
Too bad it's not free anymore - Brian McCarthy
[+11] [2008-10-17 03:40:55] Rob Windsor

One of the best kept secrets in the .NET Framework is the End to End Tracing capability. It's mostly associated with WCF but it works across client and server tiers. Check out Scott Hanselman's podcast for a good overview.

[+9] [2008-09-19 01:59:49] goodwill

NLog [1] seems to be good and +1 for Log4net.


[+7] [2009-08-11 01:40:45] S. Mills

Another logging question! Well, as I've said already, we've been using The Object Guy's Logging Framework [1] for years. It is in several of our production applications. It is easy to use and easy to extend. You can't go wrong with it.


[+6] [2009-01-31 20:45:42] community_owned

The code for Log4net may be larger than the code for your entire project. It is bloatware! Try .NET Logging Framework [1] if you want something that is easy to use and as flexible as you'll ever need.


[+5] [2009-08-17 18:35:04] community_owned

I haven't found a great one yet. Log4net is about 75% OK, but:

  • it's not asynchronous, so you tie up cycles waiting for logs to write
  • it really, reeeeaally sucks if you're using multi-threaded applications. It's more or less non-threadsafe.
  • I'm having all kinds of issues running it on 64 bit and
  • it's a pain to debug (not impossible, but I spend more time messing with log4net now than I do with business code).

I really don't understand why MS doesn't come out with one as part of .NET.

[+5] [2011-08-11 15:02:33] Brian McCarthy

NLog [1] is the best logging software for .NET becuase it allows for an easier configuration for new projects and supports Silverlight, .NET Framework 4, Windows Phone 7.x which Log4net doesn't.

The biggest problem with Log4net is that it is designed to run with Mono [2] .NET framework verson 2.0 open source version. It needs to be upgraded to provide full support for new projects on the .NET framework 4.0. [3] did a great comparison study between the most popular .NET Loggers features: SmartInspect, NLog, log4net, Enterprise Library [4], and ObjectGuy Framework. NLog comes in second place, trailing to SmartInspect which is unfortunately no longer free. With a five user SmartInspect license running for $1,199, I'll stick to NLog.

NLog's supported targets include:

  • Files – single file or multiple, with automatic file naming and archival
  • Event Log – local or remote
  • Database – store your logs in databases supported by .NET
  • Network – using TCP, UDP, SOAP, MSMQ protocols
  • Command-line console – including color coding of messages
  • E-mail – you can receive emails whenever application errors occur
  • ASP.NET trace
  • and more

NLog 2.0 Features:

  • very easy to configure, both through configuration file and programmatically
  • easy-to-use logger pattern known from log4xxx
  • advanced routing using buffering, asynchronous logging, load balancing, failover, and more
  • cross-platform support: .NET Framework, .NET Compact Framework and Mono (on Windows and Unix)
  • .NET, C/C++ and COM interop APIs are supported so that all your application components including legacy modules written in C++/COM can route their log messages through a common engine.
  • Asynchronous logging pipeline – fully supports async-only operations (Silverlight)
  • Wrapper Layout Renderers – can transform output of other layout renderers
  • New build system (MSBuild-based) – old build system based on NAnt [5] is no longer supported
  • New MSI-based installer – generated using WIX, NSIS-based installer is no longer supported
  • Platform-specific IntelliSense [6] – includes only supported targets and properties for each platform
  • Support for logging via Trace and TraceSource – new NLogTraceListener for integrating with legacy code
  • New exception handling rules – logging configuration errors will now throw exceptions at startup.
  • InstallNLogConfig.exe – new tool to install/uninstall logging objects (such as event log, performance counters, etc.)
  • Exception logging enhancements – long-awaited extensions to ${exception} layout renderer.
  • Support for .NET client and extended profile. All features which require .NET Extended profile have been moved to a separate assembly called NLog.Extended.dll. See the NLog.Extended project on GitHub for more details.
  • Merged NLog.ComInterop into NLog.dll itself, which means one less DLL files to deploy when using NLog through COM.
  • GetCurrentClassLogger() is now supported in .NET Compact Framework.

NLog's Compatibility List:

  • Windows.NET Framework 2.0 SP1, NET Framework 3.5 SP1
  • .NET Framework 4 Client Profile
  • .NET Framework 4 Extended Profile
  • Silverlight (Windows/Mac OS X), Silverlight 2.0, Silverlight 3.0, Silverlight 4.0
  • Silverlight for Windows Phone
  • Windows Phone 7, Windows Phone 7.1 (beta)
  • .NET Compact Framework (Windows Mobile), .NET Compact Framework 2.0, .NET Compact Framework 3.5
  • Mono (Windows/Unix), Mono 2.x profile (experimental)

[+5] [2008-11-02 22:29:24] Brian H. Madsen

I'll re-iterate what most have been saying here.

Log4net is a brilliant solution for logging - you can write your own extenders if you want behavior that's not currently supported.

We've implemented it on an enterprise sized project and it's working like a treat - very little bloat as it does exactly what you want it to do - logging - no frills, no fancy stuff, just logging.

So another ++ for Log4net.

[+4] [2009-08-11 09:50:40] Lanceomagnifico

For ASP.NET projects I find that a combination of

works great, Log4net for the main logging engine, and ELMAH for its kick-ass auto logging and emailing. I use PostSharp to modify the details about the program flow for the namespaces that I am interested in knowing about, like if you want to be able to trace logic flow and spit out return and input values.

The combination of these allows me to garner as much detail as I want. Which really helps when trying to debug a problem.


[+3] [2010-09-13 13:21:48] Dennis G.

You might also want to take a look at our (commercial) .NET logging tool SmartInspect [1]. The big difference compared to the available open source tools is that we ship a powerful monitor and log analysis tool with SmartInspect. If you have log files that exceed a few thousand entries, having a great log analysis tool is a big time-saver (especially if you work with multi-threaded, distributed or web applications).

SmartInspect also comes with log protocols and options not found in other tools and can be configured with just one line of code.


I checked this out and it's simply excellent. Easy to setup and LINQ support on an Entity Framework is outstanding. +1 for the answer. - dooburt
[+3] [2009-02-08 04:15:17] community_owned

An interesting take on logging frameworks is in the blog post Logging Frameworks [1] (2009-02-01).


[+3] [2008-09-19 04:16:27] jeremcc

I've used Log4net, and it's fine, but I've always felt that it is a tad overkill. My usual approach is to implement a logger class with methods like Error, Warning, Info and Debug which simply write to the Event Log using the standard .NET framework classes for that.

I then set up an external monitoring tool, which will monitor the Event Log for specific types of messages and send emails or write to a database or whatever. The benefit is that you don't have to worry about a third-party dependency, the code is really simple and you can find a cheap tool to do almost anything you want with it once it's been logged. I currently use PA Server Monitor [1], which is one of the best pieces of monitoring software I've seen in a while.


(1) Agree that Log4Net is overkill. It is not hard to write your own logging classes. - darasd
(1) @codeflunky - Does your approach really save that much work over configuring log4net to configure SmtpAppender and EventLogAppender? - Scott A. Lawrence
[+2] [2008-09-19 02:16:50] Mark Cidade

I think that simple Windows event log [1] or trace logging [2] is often overlooked. For SQL-Server type transaction logs, there's System.IO.Log [3].


Unless you have a mechanism for dragging your log events out of the event log I would avoid using it as a primarly logging repository. Log files are a lot easier to sift through. - Richard Ev
The Windows Event Viewer is as good as any other log viewer I've come across or built. - Mark Cidade
[+2] [2008-09-19 02:50:04] Giorgio Galante

Log4net, because it just works. And it's extremely configurable. The Enterprise Library [1] is constantly shifting. The Log4<Language> stuff is pretty mature/stable. Who knows when Microsoft will drop the Enterprise Library.

No Thanks!


[+2] [2010-09-03 09:31:43] Kermit

I've been using NLog [1] for a while now and swear by it for simple projects.

It's follows the KISS [2] mantra very well and for me that is a big plus. I think stuff like Log4net, while great and not necessarily bloatware, is like a nerdy implementation of logging and as a result it tends to be used in apps that are themselves complicated or nerdy (or both LOL).

I was actually writing a helper library to wrap the Debug and Trace classes that ship with the .NET Framework until I came across NLog, it does everything Log4net does but with less fuss (I hate all the overly complicated configuration you have to do for Log4net to get the thing to work).

For big projects, however, I do recommend the likes of Log4net as you get a whole raft of enterprise specific features that NLog doesn't have (and shouldn't as it sits perfectly well for the bedroom coder/lone developer).


I would be curious to know some of the enterprise specific features that log4net has that NLog doesn't that would cause you to recommend log4net for big projects over NLog. My company is currently evaluating logging platforms and is looking at log4net and NLog, among others. Just from looking (I don't have any production experience with either platform), it isn't obvious that there are many significant differences between log4net and NLog. Thanks - wageoghe
[+1] [2011-11-19 20:37:23] George Stocker

A compiled list of answers:

[4] http://ViewOnLog

[+1] [2010-03-06 18:22:53] BT.

I have been using Enterprise Library [1] for quite some time now and all our projects used the same database to log the information, and it is easy to configure using editor. We have been using Email and Database as two trace listeners. All the critical bugs are directly emailed to us while rest of the stuff including all the auditing data goes to a centralized database.

Whenever there is some issue, we have predefined reports that runs on top of the Enterprise Library database to pull out any reason. So I would suggest using Enterprise Library!


[+1] [2009-08-24 20:45:42] Jay Cincotta

Try GIBRALTAR [1]. Not only does it provide a non-blocking, threadsafe logging framework, it also includes a web service to collect logs and an analysis tool with extensive filtering and graphing capabilities.

Gibraltar combines benefits of ELMAH, log4net and perfmon and takes it to the next level.

Like ELMAH, Gibraltar reports errors and supports email notifications. Unlike ELMAH which only supports ASP.NET, Gibraltar works with any .NET application (services, WinForms, WPF, etc). It also includes all the events leading up to each error and can directly integrate with multiple defect tracking systems.

Like log4net, Gibraltar provides trace logging. In fact, Gibraltar can work with log4net and other logging frameworks. Unlike log4net, Gibraltar also gets the logs to your team from all the computers your application runs on and provides tools to analyze all that data.

Like Perfmon, Gibraltar collects and graphs Windows Performance Counters. Unlike perfmon, Gibraltar collects key metrics continuously in a compressed format and makes it easy to track application-specific metrics. In fact, you can log all calls to key methods including parameters and return values by simply tagging those methods with an attribute.

Gibraltar offers a free 30-day trial and deep discounts for multi-user license bundles. It's not free, but it is actively supported by a passionate, experienced team that really knows and cares about logging and application monitoring. Chat with us [2] if you have questions.


is Gibraltar free ? - ram
According to their website Single License is USD495 ( so its not a free solution, but the question doesn't indicate must be free so still valid choice. - Jafin
Yes, a single license is $495USD, but multi-user bundles quickly bring the per-developer cost down to about half that. And the data collection component is freely redistributable. You can monitor dozens of applications on thousands of computers at no additional cost. - Jay Cincotta
[+1] [2008-09-19 02:36:28] SmartyP

I can vouch for log4net... We use it in all of our .NET applications (which are large multi-tiered enterprise scale applications).

[0] [2008-09-19 02:02:14] Bullines

Depending on what you're logging, Health Monitoring in ASP.NET is worth looking into for logging instrumentation info and extending it is fairly straightforward in most situations.

[0] [2008-09-20 15:25:44] community_owned

ViewonLog [1] is useful. The good thing about this logging tool is the customizable logging policy, you can change the logging policy in run-time very easily (in the UI).


[0] [2008-09-22 10:55:25] Richard

I like log4net - it has good performance and is very flexible. More recently I've been using the logging in the MS Patterns and Practices Enterprise Libray 3.1 and 4.0 - the main reason being is the integration with the exception handling block and the policy injection - which brings with it elements of aspect orientated programming - I can add a LogCallHandlerAttribute to a method and have the entry and exit to the method automatically logged complete with the parameter values without writing a single line of code - add to this the other call handlers for exception handling and validation (from the validation block ) and you get a great productivity boost. the downside is that the entlib can be a pain to configure with lots of cruft to do in the app/web.config but they do supply a pretty nice configuration editor.

[0] [2008-10-25 13:50:00] community_owned

+10001 on log4net.

The appender model to pipe logging into multiple "sinks" as well as better buffering, ease of setup, the ability to output in the same format as java compoenents which might lie in your stack has made log4net my go to logging for the last 5+ years. Enterprise lib is heavy handed and has deployment headaches in writing to the event log by default.

As Ron Popeil sats, "set it and forget it!"

[0] [2009-12-02 01:16:25] Statyk7

For those who are using log4net, I've made a simple console to display and filter the logs by configuring receivers (the same way you configure appenders).

I mainly use it with the .NET Remoting appender/receiver, both localy and remotely ; a lot of users are using it with the UDP appender/receiver also.

It's an open source tool developed in .NET, available on CodePlex:

[0] [2010-02-14 23:27:24] Amitabh

I am working on the troubleshooting of a huge application which did not use log4net. Then I came to know about Log4PostSharp [1]. Using this, we can inject log4net code without writing any code. Have a look into this. This might be quiet useful.


[0] [2009-08-11 02:17:16] Shabbazz

What I haven't found yet in the posts is a clear distinction between tracing and logging. Think about e.g. why does almost every logging framework has an rolling(!) appender and tracing doesn't?

IMHO tracing should be off in production environments and only turned on to trace things when something bad or not expected happens. Logging on the other hand is always on because I log only exceptions or code blocks with outputs of high interest and store the information. I would send the logging informations over the wire to a central point like a database where an application administrator has easy access to it to decide further steps taken or store them in the event log where the administrator can also later collect them.

I would also send an Email when logging exceptions or not so common states of the application like "almost" timeouts occur. Tracing on the other hand can go to a local textfile because an experienced technician immediatly tries to find out what happens in the application.

I use System.Diagnostics.Trace for tracing and log4net for logging. Both are weaved in with PostSharp [1].


[0] [2010-11-27 04:59:15] logicnp

Take a look at Crypto Logger [1] - it supports filtering, multiple log targets include rotating files, tcp, event logs, etc. It supports async mode for performance-critical apps. The most useful feature is its Console UI which can open, analyse and search log files.


[0] [2011-03-03 18:24:16] Ulrich

If you want professional logging with a best practice concept that puts your data structured in a central database then you need to check out logdirector. You access the logdata in a browser and you can also set some user rights.

While I'm sure you have put a lot of effort into your product, you really need to sort your website out. The main pictures don't display in Opera 11, your main navigation does not display in IE9. - Phill
[-1] [2008-09-18 23:46:58] Esteban Araya

Edit: I copied this from another one of my answers [1] on the same topic. I've substantially changed the original answer because I'm tired of all the down-votes and can't delete the answer since it's the accepted answer.

ELMAH is particularly nice if you're using ASP.NET. One of my favorite features about ELMAH is not having to build the UI to view logged exceptions; ELMAH provides a handler that will report your exceptions. However, I've never used it for logging anything other than exceptions.

log4net, and Microsoft's EntLib are some other ideas that come to mind. These provide a lot more functionality than what you may need if all you really need is just exception logging.

Also, you may consider performance counters if what you're really trying to do is measure your application. Again, the benefit of using performance counters is that after publishing the data, you won't have to worry about build the UI to view/query the data.


(28) Hands down? I'm kind of surprised this got marked as the answer. Can someone please elaborate on what is good / better about Enterprise Library's logging? - Winston Fassett
(11) I'm also concerned that this was marked as the answer. - sontek
(1) No need to be concerned. My final solution went ahead with the enterprise library for a few reasons, firstly we were using a few other features of the library, secondly I liked the implementation and thirdly it was powerful enough for our needs. - Odd
The answer wasn't elaborate, but it made the suggestion that assisted me in finding the correct solution. I have elaborated as to why here:… - Odd
(16) I think the problem that people are eluding to is the definitive nature of the response with absolutely no discussion as to why. IMO the "answer" to this type of question should be a well-rounded discussion of the alternatives out there, along with the relative merits of each. Remember that this is not just for you, but also for other people who may ask this question in the future. - akmad
(2) Enterprise Library is a reasonable choice if you're using other parts of it already. If logging was all you wanted though, I think log4net is faster than its Enterprise Library counterpart. - Scott A. Lawrence
(3) I'd agree with akmad normally except it seems any time you have anything approaching a 'discussion' on here you need to beware the bandwagon of evangelists busting a nut to mark your post as subjective and close the question accordingly. - FerretallicA
I'm really surprised at how many people dislike the EntLib logging framework. I personally prefer log4net, but honestly, is EntLib that bad? - code4life
There are two different concepts at play here and they're often tenuous. Accepted answer is what the author ended up choosing (e.g. in their real world implementation). Most amount of votes is what the community generally (even theoretically) thinks is best. These often compete, but not always. Some questions are specific to a need, some to a theory. - John K
(3) I think the downvoting is a bit harsh here. This guy didn't mark his answer and the right one, the question asker did! - badbod99
(1) +1 to compensate for odd downvotes. Not his fault it was selected as the answer. - John Robertson