Should I use Microsoft.Extensions.Logging.ILogger<T> or Serilog.ILogger?

[Lindsey1986]

All examples of using Serilog with ASP .NET Core I see, are using Microsoft's logging interface, instead of Serilog's interface.

Is that the recommended approach now? If yes, why is that?

[daiplusplus]

In all of my work, I only use types from the Serilog.* namespace in my Serilog configuration code - the rest of the project (controllers, other services, etc) all use Microsoft.Extensions.Logging.ILogger<T> - this makes them portable to other environments where Serilog might not be available.

Very rarely have I been wanting Serilog-specific functionality elsewhere in my codebase.

[nblumhardt]

I'm the opposite way around - I only set up the Microsoft.Extensions.* interfaces so that the framework can have access to the logging pipeline. In application code, I use Serilog's ILogger and static Log.* methods exclusively.

In the end I think it's a matter of taste. I prefer the shorter method names and lack of generic type arguments in the Serilog interfaces.

I also dislike having to clutter every constructor with ILogger<T> parameters (constructor argument lists are highly-valuable real estate), and find there are usability issues once code steps out of DI and starts calling non-DI-instantiated classes that want to do some logging (more parameter passing).

YMMV!

Serilog is currently available in all environments supported by Microsoft.Extensions.Logging that I'm aware of, plus several more. :-)

[daiplusplus]

@nblumhardt

I also dislike having to clutter every constructor with ILogger parameters (constructor argument lists are highly-valuable real estate), and find there are usability issues once code steps out of DI and starts calling non-DI-instantiated classes that want to do some logging (more parameter passing).

You can accept ILoggerFactory as a constructor parameter and use the generic call inside your ctor body instead of accepting a ILogger<T> directly - or even just ILogger if you don't care about having an automatically-generated Category value:

public MyController(ILoggerFactory loggerFactory) {
    this.log = loggerFactory.CreaterLogger<MyController>();
}

I use T4 for generating constructors for DI a lot, actually - which helps with the ergonomics of having more than a few constructor parameters. It's available here if you're interested: https://gist.github.com/Jehoel/f395a419e9d70c4a718284fdfeef007b - it has special-handling for logging as well.

[Lindsey1986]

Thank you all. I'm going with Serilog's ILogger and static Log.* methods then.

[sungam3r]

Do not forget that you can go the third way - do not use either the first or the second. Creating your own abstraction is a good option if you are going to build a large system with your own library stack. In this case, by creating your own dependency, you protect against possible problems when changing dependency versions. The specific implementation of logging is placed in a separate package. I mean implementation since Serilog.ILogger is not a just interface. Even if you use ILogger, you still make a dependency on the entire package (with the specific version) where the whole implementation is located.

[utsabshrestha]

How to use Serilog ILogger, can anyone show me the way ? Cause in every tutorial and all around , everybody are using Microsoft.Extensions.Logging.ILogger and injecting ILogger to log. How to inject Serilog ILogger and use in other class?
@nblumhardt @Lindsey1986 @Jehoel

[daiplusplus]

@utsabshrestha You should ask that on StackOverflow

[ltbyun]

@Jehoel why should ask on stackoverflow? it should be in document or wiki. it is a common use case, should not ask in stackoverflow.

[computersarecool]

Lucky for you all somebody already did ask it on Stack Overflow.