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.

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:

<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 documentation, TraceListener Class ^[1].

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.

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.

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

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!

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

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

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.

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.

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.

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.

DotNetLogging.com ^[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)

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.

For ASP.NET projects I find that a combination of

• Trace.axd
• Log4net ^[1]
• ELMAH ^[2]
• PostSharp ^[3]

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.

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.

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

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.

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

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!

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

A compiled list of answers:

• LogPost4Sharp ^[1]
• Log2Console ^[2]
• ViewOnLog ^[3]
• GIBRALTAR ^[4]
• NLog ^[5]
• SmartInspect ^[6]
• DotNetLog ^[7]

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!

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.

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

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.

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

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.

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

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/

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.

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

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.

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.

http://www.logdirector.com

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.