.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:
- Built-in logging providers from Microsoft Extensions
- Console
- Debug
- EventSource
- EventLog
- Additional Microsoft packages
- Custom implementations of ILoggerProvider
- Third-party logging providers
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:
- Group logs together for easier processing by setting log scopes with a BeginScope method
- Use structured or semantic logging as opposed to the typical logs with string.format().
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:
- Console
- Debug
- EventSource
- EventLog (only on Windows)
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 through one-click platform integration.
If you’re ready to move beyond basic logging and benefit from a robust solution, you can try Railtown AI for free.