Introduction

In my previous article, I discussed the basics of the log4net logging package. I gave an overview of the 5 levels of logging that the library provides, and examples of the different type of appenders that can be used for outputting data to your logs. In this article, I'd like to give some information on how to use log4net effectively.

Specifying different logging levels for different modules

Sometimes within your application, you will want more logging information from some areas, and less from others. Log4net facilitates this by allowing different logging levels for different loggers. An example of this is shown in LogTest3 and LogTest4.

Within this XML fragment, we can see that the root logging level is set to "FATAL". That means that only FATAL error messages are logged. We can see however that this is overridden for LogTest3 and LogTest4 to the "DEBUG" and "INFO" levels accordingly. When we run this application, we will see then that LogTest3 logs everything from DEBUG level whereas LogTest4 logs everything from INFO level onwards.

Using this technique of specifying different log levels for different parts of your application gives you a great flexibility.

Should I log or not?

In general, the more logging you have, the greater flexibility you have and the easier it is to find out what's going wrong with your program. Don't get me wrong, logging is no substitute for debugging your program thoroughly, but there's always the case when you have deployed your application and you want to know exactly what's going on.

Sometimes, the cost of logging can be expensive, particularly when performance of your application is paramount (imagine logging every DEBUG statement to a database). Obviously, the first thing to do here, is turn down the logging level so that only the relevant information is produced (e.g., WARNINGs and above). This is a good start, but what if the cost of construction of the logging message is great (e.g., you have an expensive .ToString() method)?

logger.Debug("Expensive object value="+ExpensiveObject.ToString());

The ILog interface (of which all your loggers are implemented) provides a set of methods that enable you to check if a particular logging level is being used. These methods are shown below:

The threshold can also be set to one of DEBUG, WARN, INFO etc. to set the threshold for the specified appender irrespective of the logger being used.

That's all

That's the end of the brief introduction to logging using log4net. I hope you've enjoyed these articles, and I hope I've convinced you that logging is worthwhile and fun!

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

I very much appreciate your efforts. Aside from needing to go through the message postings to resolve the Visual Studio configuration file naming issue, I found the material to be very much of the cut-n-paste, "hey, it works!" variety -- exactly what I was looking for to establish a base to be expanded within the framework of my own software.

for example I should have a healthLogger which should use HealthAppender to write to HealthMessagesLog.txt, and similarly i should have a commandMessageLogger which should use CommandMessageAppender to write to CommandMessageLog.txt ...

I am using Log4Net for logging my app errors. I've a configuration file in my application for reading information about the database and its connection. How can i use this Configuration file to supply values to the Log4Net Configuration file. for connection string, connectionType and command text value. Anyone know this????

I did the coding that uses log4net ADOnetAppeder.. I was wondering of writting an article that describe the db portion of log4net but later thought to share it with u so then u can just update this article to have it as well..

:-OYou can replace the static calls to DOMConfigurator.Configure() with an attribute on your DLL. The first time you call LogManager.GetLogger(), it will look for this attribute on your DLL, and if found, use the configurator it indicates.

This adds a nice auto-configure ability and lets you eliminate all the self-starter code, which is especially useful if you have lots of potential logging entry points in your application and no clean single entry point to run the configuration.

Simply put this code in your AssemblyInfo.cs file...

// This attribute tells log4net to use a .config file for loading setup information,
// and then watch the config file for changes, reloading if any changes occur.T
//
// The first call to LogManager.GetLogger will cause log4net to check for this attribute,
// and then attribute will tell log4net to look for the application config file. For
// ASP.NET applications this is a web.config file, and for managed .EXE's this is a
// config file named application.exe.config. You can print the name and location of the
// current config file using code like this:
//
// System.Diagnostics.Debug.WriteLine( "Using config file: " +
// System.AppDomain.CurrentDomain.SetupInformation.ConfigurationFile );
//
[assembly: log4net.Config.DOMConfigurator(Watch=true)]