Popular Error Logging Libraries For .NET

Part I

This article is in continuation with our previous article on the same. The article discuss some effective error handling strategies that you could use in your projects.

Common Error Logging libraries for .NET

For .NET framework, the most popular logging libraries are probably log4net and NLog.

Although, there are differences between the two, the main concepts are similar.

In NLog, for instance, you will basically create a static logger instance in every class that needs to write anything to the log:

private static Logger logger = LogManager.GetLogger(“LoggerName”);

To write to the log, you will simply call a method of that class:


As you have noticed, you have not yet specified where you want to log the errors. Instead of hard coding this information in the application, you will put it in the NLog.config configuration file:

<?xml version=”1.0" encoding=”utf-8" ?>

<nlog xmlns=http://www.nlog-project.org/schemas/NLog.xsd



<target name=”logfile” xsi:type=”File” fileName=”errors.log”

layout=”${date:format=yyyyMMddHHmmss} ${message}” />



<logger name=”*” minlevel=”Error” writeTo=”logfile” />



The above configuration says that all errors will be logged to the errors.log file and accompanied with a timestamp.

But, you can easily specify a different type of target instead of a file or even add additional targets to log the errors to multiple locations.

With the layout feature, you can define which additional metadata you want to log along with the message. Different targets have different additional attributes to further control the logging process, e.g. archiving policy for log files and naming based on current date or other properties.

Using the rules section, you can even configure logging of different errors to different targets, based on the name of the logger that was used to emit the error.

Log levels can add additional flexibility to your logging.

Instead of only logging errors, you can log other information at different levels (warning, information, trace…) and use the minlevel attribute to specify which levels of log messages to write to the log and which to ignore.

You can log less information most of the time and selectively log more when troubleshooting a specific issue.

Analyze Production Log Files

Logging information about errors is the first step.

Based on the logged information, you can detect any problems with the application and act on them, i.e. fix them to ensure that the application runs without errors in the future.

In order to do effectively, the following tips could be helpful:

  • Receive notifications when errors happen
  • Collect similar errors in groups, so that you do not need to check each one of them individually.

As always, there are ready-made solutions for these problems available so that we do not need to develop them ourselves.

A common choice in .NET ecosystem is Application Insights. It is an Azure SaaS (Software as a Service) offering, with a free tier to get us started, and a usage based pricing model.

The product is integrated into VS. There is a wizard present to add Application Insights telemetry to a running project or to a newly created one. It will install the required NuGet package, create an accompanying resource in Azure and link the project to it with configuration entries.

Logged data can be analyzed in Azure Portal or inside Visual Studio.

If you want keep all the information on-premise, there is an open source alternative available: OneTrueError.

Before you start using it, you need to install the server application on your own device.

There is no wizard available for configuring OneTrueError in your application, but the process is simple:

- Install the NuGet package for your project type, e.g. OneTrueError.Client.AspNet for ASP.NET applications.

- Initialize automatic exception logging at application startup, e.g. in ASP.NET applications, add the following code to your Application_Start method (replace the server URL, app key and shared secret with data from your server, of course):

var url = new Uri(“http://yourServer/onetrueerror/");

OneTrue.Configuration.Credentials(url, “yourAppKey”, “yourSharedSecret”);


Both Application Insights and OneTrueError solve another problem with log files: large modern applications which has multiple services and are installed on multiple machines for reliability and load balancing.

Each service on each machine creates its own log and to get the full picture, data from all these logs needs to be consolidated in a single place.

By logging to a centralized server, all logs will automatically be collected there with information about its origin.

Error handling specifics for Mobile Applications

Just like Application Insights and OneTrueError provide a complete solution for server application, there are dedicated products available for mobile applications.

Basically, they are not limited to error or crash reporting but also include support for usage metrics and (beta) application distribution.

Microsoft’s associate to Application Insights for mobile and desktop applications is HockeyApp, but there are other alternatives as well, like Raygun and Crashlytics. They have similar attribute set and differentiate themselves by varying support for specific development platforms and pricing models.

Most of them require only a couple of lines of code to get started.

Keep coding!

Let us know your opinion in the comments sections below. And feel free to refer Microsoft’s site to gather more information.

If you want to improve your skill in Dot Net Course and excel yourself in Dot NET training program; our institute, CRB Tech Solutions would be of great help and for you. Come and join us with our well structured program for the best Dot Net Course. Among many reputed institutes, CRB Tech has craved its niche among the best dot net institutes.

Stay connected to CRB Tech for more technical optimization and other updates and information.