Serilog DI in ASP.NET Core, which ILogger interface to inject?

Choosing which interface to use within your application is a matter of taste, really. If you prefer Serilog’s ILogger shorter method names (e.g. log.Error vs log.LogError), go with that, otherwise use the Microsoft’s generic ILogger<>. You have control over all the dependencies you use in your own projects, so there’s no strong technical reason to prefer one over the other.

You might be interested in reading this issue on Serilog’s repo:

Should I use Microsoft.Extensions.Logging.ILogger or Serilog.ILogger?.

I personally use Serilog’s ILogger across all my projects not only because I do prefer the shorter method names, but also because I prefer not to inject a logger in every single constructor of every class, and it’s also easy to have a contextual logger for every class using Log.ForContext<>, which is useful when troubleshooting issues. E.g.

public class SomeService
{
    private readonly ILogger _log = Log.ForContext<SomeService>();
    // ...
}

public class SomeRepository
{
    private readonly ILogger _log = Log.ForContext<SomeRepository>();
    // ...
}

If you were developing a library though, I’d recommend using Microsoft’s generic ILogger<>, of course, instead of taking a dependency on Serilog and force consumers of your library to also take a dependency on Serilog.


Log.Logger is thread-safe, thus registering as a singleton as you are doing above is correct if you want all classes to share the same instance (without SourceContexts) – nothing wrong with that.

Leave a Comment