How Logging Works in C#

In this post, we’ll see how to create logs inside our C# applications.

In this post, I want to focus on their internal workings, on why to use one interface or another, since we already covered what logs are in another post.

If you don’t know what a log is, or how to set up your application to use logs, I recommend you read that post first. 

1 - The Logging Interfaces in .NET

In C#, we have 3 different interfaces related to logs.

• ILogger: The interface responsible for writing the log, be it to a file, the terminal, or the cloud, wherever you’ve configured it.
• ILoggerProvider: The interface responsible for creating an instance of ILogger. Under normal circumstances, you don’t need to use this interface.
• ILoggerFactory: The interface that registers and stores all the ILoggerProviders.

So how does this apply in the real world? 

In the previous post, we saw that by using the Serilog library, we could write logs both to the console and to Graylog. 

loggerConfiguration.WriteTo.Console(consoleLoggerConfiguration.MinimumLevel)

loggerConfiguration.WriteTo.Graylog(graylogLoggerConfiguration.Host, graylogLoggerConfiguration.Port, TransportType.Udp, graylogLoggerConfiguration.MinimumLevel)

What we are actually doing behind the scenes is creating two providers, one for the console and one for Graylog. We use Serilog for this, because by default .NET does not provide an interface capable of logging to Graylog or even to the file system, it just does so to the console. 

Finally, when we call the ILogger interface, we’ll receive all the providers with their respective implementations, and the message will be written to all of them.

2 - Injecting Logging Into Services

Currently, if you create a project with .NET 6, the WeatherForecastController comes by default in the template. This controller includes a logger, injected as ILogger<WeatherForecastController>, which already gives us a clue of what we need to do. 

When it comes down to it, we have two options: inject the generic logger ILogger<T> or inject the factory ILoggerFactory.

The difference lies in the process of creating the ILogger interface that will actually write the message. 

If we inject ILogger<T> it creates an ILogger behind the scenes with the category "ProjectName.Controllers.WeatherForecastController"

On the other hand, if we inject the ILoggerFactory interface, we must specify the category ourselves.

loggerFactory.CreateLogger("ProjectName.Controllers.WeatherForecastController");

Keep in mind that by default, this option creates an ILogger, not an ILogger<T>. To do that, you’d have to use .CreateLogger<T>(..)

If you use this second option, you’d be violating the single responsibility principle, so it’s not the best choice. 

The first option, injecting ILogger<T>, seems more appropriate. But, at the same time, including T is somewhat redundant, not every case will require it. 

Therefore, simply injecting ILogger in most places would be ideal, but by default, Microsoft’s library won’t let you.

In my personal view, this is a bit of a “you have to jump through hoops” kind of situation, but honestly, it’s not the end of the world to have a decorator.

Conclusion

Lastly, I’d like to highlight the naming of the interfaces, both Factory and Provider. I have to say that I love these names and have used them constantly throughout my career when I’ve implemented code with a similar structure.

In this post, I’ve outlined the current state of the logger in .NET and shared my thoughts about it.