Expose 'IServiceProvider' on new 'UseSerilog' overload

[julealgon]

The existing UseSerilog overloads do not provide access to the underlying IServiceProvider and thus don't support any kind of dependency injection.

I needed to check a settings class on my side using IOptions<T> and use these values as paraments to sink configuration. I ended up moving the log configuration into the startup class, dropping the use of UseSerilog and instead relying on ILoggerFactory.AddSerilog inside a custom configuration class that I injected inside the Startup's Configure method.

If the IServiceProvider used in the singleton registration inside UseSerilog was exposed as one of the parameters, I could've leveraged that to fetch my options instead.

From what I gathered from the implementation, it would just be a matter of moving some of the code inside the AddSingleton lambda, firing the user-provided lambda there and thus having access to the IServiceProvider.

[sungam3r]

Agree, exposing IServiceProvider from some AddXXX/UseXXX overload is a universal way to integrate user code with DI.

[ralphhendriks]

Good suggestion.

However, we should be aware that

dropping the use of UseSerilog and instead relying on ILoggerFactory.AddSerilog inside a custom configuration class that I injected inside the Startup's Configure method.

will cause logging to only be configured properly after the call to ConfigureServices. So logging during host construction (or earlier) will not be through Serilog. We should probably extend the documentation of ways to deal with this. I need to experiment more with this myself, though.

[ralphhendriks]

Currently, we have the following two extension methods on IWebHostBuilder available

UseSerilog(
    this IWebHostBuilder builder, 
    ILogger logger = null, 
    bool dispose = false,
    LoggerProviderCollection providers = null)

and for inline initialization

UseSerilog(
    this IWebHostBuilder builder,
    Action<WebHostBuilderContext, LoggerConfiguration> configureLogger,
    bool preserveStaticLogger = false,
    bool writeToProviders = false)

Would it be sufficient (as a first step) to add a third overload, also for inline initialization

UseSerilog(
    this IWebHostBuilder builder,
    Action<WebHostBuilderContext, LoggerConfiguration, IServiceProvider> configureLogger,
    bool preserveStaticLogger = false,
    bool writeToProviders = false)

Would that do it for you, @julealgon?

[julealgon]

Would it be sufficient (as a first step) to add a third overload, also for inline initialization
Would that do it for you, @julealgon?

Yep, that sounds like what I'd do as well from the library side @ralphhendriks . As long as I can tap into the container during configuration I'm good :)

[nblumhardt]

👍 would be great to see what this entails.

[douglasg14b]

Very much need this, things like the DB connection string are encrypted, and it's decryption is handled by an injectable service.

I'm very unsure of how to configure serilog to actually write to our DB when I require DI support to configure it.

[nblumhardt]

Related, but WIP: https://github.com/nblumhardt/serilog-reload

[nblumhardt]

Shipped in 3.4.0 (via version 3.1.0 of Serilog.Extensions.Hosting)