What is the best logging solution for a C# .NET 3.5 project

Question

Hi,

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. There are two questions I have if anyone knows the answer.

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

Thanks Daniel

Answer 1

Edit: I copied this from another one of my answers 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.

Answer 2

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.

Answer 3

The problem with the Enterprise Library 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.

Answer 4

Can't vote up, but +1 for Log4Net, and NLog seems good too.

http://www.nlog-project.org/

Answer 5

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.

Answer 6

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 on a number of projects.

It's small, configurable, reliable and free!

Answer 7

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

Answer 8

i can vouch for log4net.. we use it in all of our .net applications (which are large multi-tiered enterprise scale apps)..

Answer 9

Log4Net, because it just works. And it's extremely configurable. The Enterprise Library is constantly shifting. the Log4 stuff is pretty mature/stable. Who knows when Microsoft will drop the Enterprise Library.

No Thanks!

Answer 10

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 (i.e 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 app config 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 app config:

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

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

To learn more about Trace/Debug check out:the docs here.

Answer 11

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, which is one of the best pieces of monitoring software I've seen in a while.

Answer 12

I'd recommend NLog, it's as powerfull as Log4Net but with easier configuration. (IMO)

Answer 13

You could use Common.Logging. 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.

Answer 14

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

Answer 15

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.

Answer 16

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.

http://www.hanselminutes.com/default.aspx?showID=68

Answer 17

+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!"

Answer 18

I don't have the reputation score yet to vote an answer up or down so 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 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

Answer 19

The code for Log4Net may be larger than the code for your entire project. It is bloatware! Try this if you want something that is easy to use and as flexible as you'll ever need.

Answer 20

This guy has an interesting take on logging frameworks.

Answer 21

Another logging question! Well, as I've said already, we've been using The Object Guy's Logging Framework 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.

Answer 22

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-admin has easy access to it to decide further steps taken or store them in the event log where the admin 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 loggin. Both weaved in with PostSharp

Answer 23

Hi, For asp.net projects I find that a combination of:

• Trace.axd
• Log4net - logging.apache.org/log4net/index.html
• ELMAH - code.google.com/p/elmah/
• PostSharp - www.postsharp.org/

Works great. Log4Net for the main logging engine. ELMAH for it's 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.

Cheers, Lance

Answer 24

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

Answer 25

Try GIBRALTAR. 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 if you have questions.

Answer 26

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: http://log2console.codeplex.com/

Answer 27

I am working on the trouble shooting of a huge application which did not use log4net. Then I came to know about log4PostSharp. Using this we can inject log4Net code without writing any code. Have a look into this. This might be quiet useful.

http://code.google.com/p/postsharp-user-plugins/wiki/Log4PostSharp

Answer 28

I have been using Enterprise Library for quite some time now and all our projects used the same DB to log the information, 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 DB.

Whenever there is some issue, we have pre defined reports that runs on top of enterprise library database to pull out any reason. so i would suggest using Enterprise Library!

Answer 29

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

It's follows the KISS 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 config 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).

Adios,

T

Answer 30

You might also want to take a look at our (commercial) .NET logging tool SmartInspect. 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.