.NET Error Logging Basics: Everything You Need To Know About Logging


Marwan Haddad

August 22, 2022

8 Min


.NET Error Logging Basics

While .NET is one of the most loved frameworks according to Stack Overflow Developer Survey for 2021, that popularity can bring issues for .NET error logging. 

There are “hundreds of thousands” of .NET packages available on NuGet, so developers can end up with an overwhelming tech stack to simply analyze .NET performance and monitor errors.

How can you efficiently debug your code even as it scales up with all the third-party libraries you might use and their associated configurations?

One simple but commonly overlooked answer: logging.

Key Insights

In this guide, we will go through .NET error logging across the following categories:

  • What is logging?
  • Client-side vs. server-side logging
  • Logging in .NET
  • Logging locations
  • Log types
  • Log levels
  • Logging libraries
  • Mobile vs. desktop vs. web logging
  • External logging resources
  • Simplify Your Logging Process

What is Logging?

Logging is the practice of recording the alerts and messages that you get about the state of your code. As your application may run into inefficiencies, errors, or even crash, you can save the associated messages together with all the relevant context.

Any message about the performance of your code shows up within the relevant logging target, helping you:

  • Read and understand error messages
  • Isolate bugs
  • Detect the root cause of a crash
  • Search and extract statistics about your code’s performance.

How can you preserve this context for potential future debugging?

By explicitly logging relevant messages in a consistent and structured way, which you should set up before your application ever crashes.

Client-Side vs. Server-Side Logging

While your app is in the development phase, every error or alert message about the state of your code is easily accessible to you and your team.

But once you ship to production, certain errors may never show up within your internal system unless you take the time to set up additional logging.

To do so, understand the key difference between two types of logging:

  • Server-side logging: recording the alerts and messages that you receive from within your internal server and coding environment while testing, debugging, and building your application.
  • Client-side logging: capturing and recording the alerts and context around any errors and bugs appearing for your application’s users once you’ve shipped your code to production.

Both categories of logging involve their own best practices and a level of nuance, but in this guide we will focus on how you can set yourself up for server-side logging.

Logging in .NET

A basic server-side logging set-up doesn’t require any additional or third-party tools. 

.NET already ships pre-packaged with several methods and logging targets you can use to capture relevant information. In fact, .NET goes even further as it automatically detects and logs most crashes within Windows Event Viewer.

So why should you log errors manually besides automatic reports? 

The main reason is the ability to customize error messaging and reporting. With larger projects and in teams of multiple people, logging is a key tool for you to streamline your application development from the initial testing to production and customer support. 

While logging is most commonly done through the LogInformation() method, some other key methods can help you do the following:

  • Create logs
  • Configure logging 
  • Set log level
  • Filter logs
  • Apply log categories
  • Define log message templates
  • Specify log exceptions
  • Define log scopes.

Logging Locations

While logging in .NET is most commonly done in Windows Event Viewer, there are many other potential logging locations you can take advantage of.

The solutions for logging can be split into a few key types:

  • Database
  • Relational Database
  • NoSQL Database
  • Time-series Database
  • Searchable Log Solution
  • Error Monitoring Tool
  • File
  • Console
  • Trace
  • Event Viewer (Windows Event Log)
  • Event Tracing for Windows (ETW)

Then, specifically for .NET logging providers also fall into 3 key categories as follows:

  • Console
  • Debug
  • EventSource
  • EventLog
  • Additional Microsoft packages

You should also keep in mind that logging is different for apps with a Generic Host versus non-host console apps.

Log Types

Your logs can be default, as defined by whatever solution you choose (whether provided by Microsoft or a third-party). 

You can customize your .NET logging in 2 key ways:

Structured logging is a bit more complicated but has some of the following benefits:

  • Preserving additional parameters like message-template and message-parameters
  • Simpler grouping of events
  • Faster search for logs from a specific user
  • Additional formatting capabilities

Log Levels

The messages recorded in your console can encompass multiple levels ranging in severity for your overall application performance.

These log levels can help you prioritize and triage errors during your debugging process. In .NET there are 4 key log levels that are recorded by default:

  • Information: messages about application progress, runtime, etc.
  • Warning: alerts when your code may have an inefficiency or risk encountering an error
  • Error: outputs error messages, such as when part of your code has encountered an exception
  • Critical: significant errors that cause your entire application to crash.

The exact state and appearance of these messages may change based on the exact environment that you’re using.

While by default logs of “information” or higher are logged, you can also enable logs for other message types, such as:

  • Trace
  • Debug
  • None 

You can set log level to ensure that any messages at a specific level or higher get logged. The way you configure log level customization should change between development and production environments to best serve your needs at those different stages. 

In development you may want to enable all or most alerts to make sure you have the most accurate picture of your code’s performance. On the other hand, in production you probably want to log only the highest priority alerts such as warn, error, and critical messages. Prioritizing those alerts can help you avoid wasting storage on lower-priority entries and to protect sensitive client information. 

Logging Libraries

While there are many available logging libraries for .NET, 4 free solutions are the most popular:

  • log4net: oldest and not that popular with newer projects because it is difficult to set up and configure.
  • NLog: easy to set up with an API, fast, and supports 96 different targets with no customization required.
  • Serilog: one of the newest solutions, focused on structure logging with easy out of the box implementation and customization.
  • Microsoft.Extensions.Logging: built-into .NET Core which allows you to set up where messages should be logged, whether from default providers or custom implementation.

External Logging Resources

There are many third-party logging providers beyond those listed above. Microsoft lists the following frameworks:

Rather than just using a ready logging framework, you can also implement a custom logging provider in .NET. 

Logging on Web vs. Desktop vs. Mobile

The .NET family includes three different products: 

  • .NET Framework for Windows
  • .NET Core for cross-platform cloud applications
  • Xamarin for cross-platform mobile applications
  • Xamarin for desktop MacOS applications

As such, logging looks different depending on which product you are working in.

Logging in Desktop Applications (Windows)

With desktop .NET applications you can use Microsoft’s logging API

The API integrates with built-in Microsoft providers and third-party solutions. 

You need to create a logger object with the generic ILogger<TCategoryName> or a dependency injection. Prior to .NET 6 logging services registered a specific ILogger type.

Logging in Desktop Application (MacOS)

While building Mac applications with Xamarin.Mac you can log in Visual Studio for Mac, Xamarin Studio, Xamarin “Universal” Installer, or Xamarin Build Host.

To find your logs in either of those locations, you can use Finder’s built-in “Go to Folder” functionality with one of the predefined paths.

Logging in Web & Cloud Applications

When logging for web applications with ASP.NET Core, you need to consult the specific frameworks of your logging provider who will store your logs. You can also enable multiple logging providers to best serve your needs.

Default web app templates for ASP.NET Core use the Generic Host and add these logging providers through the CreateBuilder method:

Logging in Mobile Applications

When building applications for iOS or Android you can benefit from the logging functionality within Xamarin.

You can use App Center Test when logging for native and hybrid mobile apps.

Within the Android implementation of Xamarin you cannot make direct calls to the console so instead you have to retrieve “logcat” entries from the Android log. You can do so with Xamarin’s Android Debug Log tool.

On iOS you can use the Visual Studio for debugging or access the iPhone console through Xcode or the Apple iPhone Utility.

Debugging .NET Errors

Microsoft recommends you follow these 3 key logging steps:

  • Define a logger message
  • Define logger message scope
  • Optimize log levels

Make sure that you also set up logging exceptions for error handling, with specific code that runs when a particular exception or error occurs.

You also need to remember that more context will help you with debugging, so set up your logging solution to record that context with error messages. 

When logging errors on client-side, you also need to implement controls so that you always redact sensitive customer information from your logs.

Moving Past Built-In Logging Solutions in .NET

Proper logging is essential if you hope to catch any .NET errors early and to help you with any future debugging.

By properly recording any alerts as they come in, whether in development or production, you can save time for yourself and your team when any problems do pop up.

While the built-in .NET logging methods can be powerful, as your application scales, you might also consider a more powerful solution. Additional logging tools can help you organize information and provide you with the complete context around any . NET error to track down its root cause.

Railtown AI’s .NET error logging and debugging solution can help you leverage the full power of .NET’s error messages with automated insights and alerts powered by AI.

If you’re ready to move beyond basic logging and benefit from a robust solution, you can try Railtown AI for free.

Keep reading

Root CauseHow AI Can Detect Software Bugs and Root Cause Analysis

Software bugs can be a significant source of frustration for developers and users alike. These errors in code can lead to crashes, data loss, and other issues that can negatively impact the user experience. Identifying and resolving software bugs is crucial for ensuring the quality and reliability of software applications. Artificial intelligence (AI) advances have made it possible to detect and diagnose software bugs more quickly and accurately than ever before


Marwan Haddad

March 29, 2023

5 Min


AppInsightsHow AI Can Help Your Company Save Time on Creating Release Notes

With our Release Notes solution, you can save time for your team by generating all of your release notes automatically. What’s more, our product will give you the freedom of choosing the final format for all of your release notes, be it a summary, a short list, or a full page.


Marwan Haddad

February 6, 2023

3 Min


Root CauseMachine Learning for Solving Root Cause Application Errors & Failures

In today's world, even a single application error could have significant consequences for both businesses and individual developers. From lost revenue and damaged reputation to disrupted services and frustrated customers, the cost of not addressing bugs in your code can be quite high.


Marwan Haddad

January 18, 2023

5 Min