Logging Frameworks are code libraries, which help developers to add flexible log output to their application.

The developer is only required to write a simple line where he wants to create a log message:

logger.Error("An error has occurred");

Only the configuration of the logging framework defines, where this message is written to (e.g. to a file, to the network, into a database or as an E-Mail). Logging frameworks offer very powerful and flexible ways to control, whether the messages are to be sent to multiple targets or if some messages should be sent to special targets or even dropped, depending on the severity of the message or the component, which created the message. Additionally, by using predefined layouts or defining custom layouts there are manifold possibilities to format the log output. 

Due to the variety of their various output channels, the power of their configuration and their maturity, logging frameworks are preferable to own logging codes being self-written. All above mentioned frameworks are open source projects. 

One can configure a logging framework by an XML file or programmatically. Using an XML file has the big advantage that the log settings can be changed without recompiling the application. All logging frameworks even allow the modifying of configuration files and instigate the changes while the application is running. 

Log4j, log4net, log4cxx, log4php 

The history of managed logging frameworks starts with log4j. This Java library has been the de-facto standard in the Java world since 2004 . 

In the following years implementations for .NET (log4net), C++ (log4cxx) and PHP (log4php) were developed. Although they follow the proven log4j-approach, they are native implementations in and for their respective platform and they incorporate their possibilities and conventions. 

Log4j and log4net have been used in countless software projects and have been proven to be reliable and mature. The available appender and layouts are sufficient for most of the requirements. For special purposes, it's not very difficult to implement own appenders. 

Log4net is now an official project of the Apache Foundation. The latest version 1.2.11 was released in October 2011. 


NLog is an alternative logging framework, initiated and maintained by Jarek Kowalski. Inspired by log4j and log4net, NLog offers numerous new approaches and ideas and is being continously developed and improved. 

However, one has to take the necessary precautions when switching an application from log4net to NLog. The necessary code changes are easy. Also, the NLog configuration file has a similar structure and can be apparently converted 1:1 from log4net. But if file targets are being used, it can happen that the application runs much slower after the switch to NLog. This is not caused by the fundamental speed difference between NLog and log4net, but by the different default behaviour of the NLog file targets. The log4net file appender keeps the log file permanently open; the NLog file target by default opens and closes the log file for each log message. If this is changed by setting the file target attribute "keepFileOpen" to "true", the NLog file target runs as fast as the log4net file appender.

Which framework should I take?

.NET developers are given a choice between two good logging frameworks, log4net and NLog. 

Maturity and broad adoption speak for log4net. When you are using other frameworks which on their part also use log4net (e.g. the object-relational mapper NHibernate), it is recommended to use log4net. The same is true for those, who have some experience with log4net. When it presents no immediate problems there is no urgency to switch the framework. 

The advantage of NLog is its continuous development and some exiting new possibilities. 

Log4View 2010.3 supports the log4net file-, UDP-, TCP- und database appenders and can read XML-formatted NLog files. 


Log4View supports both log4net and NLog.