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.
In this guide, we will go through .NET error logging across the following categories:
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:
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.
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:
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.
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 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:
Then, specifically for .NET logging providers also fall into 3 key categories as follows:
You should also keep in mind that logging is different for apps with a Generic Host versus non-host console apps.
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:
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:
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:
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.
While there are many available logging libraries for .NET, 4 free solutions are the most popular:
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.
The .NET family includes three different products:
As such, logging looks different depending on which product you are working in.
With desktop .NET applications you can use Microsoft’s logging API.
The API integrates with built-in Microsoft providers and third-party solutions.
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.
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.
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.
Microsoft recommends you follow these 3 key logging steps:
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.
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.
Railtown is happy to announce that root cause discovery is now available for teams that run on NodeJS.
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.