Consider a way to configure logging provider using the DI system

[davidfowl]

This code always looks a little bizzare:

public void ConfigureServices(IServiceCollection services)
{
    ...
}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole();
    ...
}

The fact that hosting adds the default ILoggerFactory is fine, but having to resolve it in Configure to add logging providers seems anti to how we've integrated the rest of the stack (it feels bolted on). Also, configuring logging in ConfigureServices would mean the only thing we configure in Configure would be the http stuff (for the most part).

Proposal 1

The default logger factory should resolve an IEnumerable in its ctor.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.AddConsoleLogger(LogLevel.Debug);   
}

public LoggerFactory(IEnumerable<ILoggerProvider> loggerProviders)

The only downside if that more extension methods get added to IServiceCollection but meh.

Proposal 2

Add LoggerOptions and hang an IList off it.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.Configure<LoggerOptions>(options => 
    {
        options.Providers.AddConsole(LogLevel.Debug);
    });   
}

/cc @DamianEdwards @lodejard @rynowak

[lodejard]

All of those changes would make the logging configuration more complex, and also defer when logging "kicks in". By adding the logging provider as early as the startup class ctor in plain-old-c# you can also write messages in the configure services method, much earlier than when the options system and IOC is active.

Also with the Program.Main hosting model we might also want to add a way to pass an application-created ILoggerFactory in to the web host builder.

So yeah, end of the day I think a number of subsystems like IFileProvider, IConfiguration, ILoggerFactory are designed with IoC in mind, and may be added like services, but it's not a good idea to go the rest of the way and make their activation and building depend on DI or options.

[davidfowl]

All of those changes would make the logging configuration more complex, and also defer when logging "kicks in". By adding the logging provider as early as the startup class ctor in plain-old-c# you can also write messages in the configure services method, much earlier than when the options system and IOC is active.

That doesn't need to change. You can still inject the ILoggerFactory to create loggers but you don't need to add the providers there. We don't even have to block the fact that you can add providers at runtime I just think it should be doable via the DI system as well.

Also with the Program.Main hosting model we might also want to add a way to pass an application-created ILoggerFactory in to the web host builder.

That doesn't make it any cleaner but we should allow for that as well.

So yeah, end of the day I think a number of subsystems like IFileProvider, IConfiguration, ILoggerFactory are designed with IoC in mind, and may be added like services, but it's not a good idea to go the rest of the way and make their activation and building depend on DI or options.

IConfiguration maybe but IFileProvider feels different. You mostly want to be able to get a a specific IFileProvider so some indirection is needed. I don't see how this complicates the logger factory anymore than it is right now...

[davidfowl]

@lodejard What if we make this a concern of Hosting instead? We resolve IEnumerable<ILoggerProvider> and call AddProvider on the ILoggerFactory created in Hosting.

[lodejard]

I could see that as an extra step we add, right after the host gets control back from ConfigureServices and creates the service provider?

[davidfowl]

Yep

[muratg]

@davidfowl @lodejard do we have an agreement here?

cc @Eilon

[cwe1ss]

+10! I think it would be great if Logging could be configured as early as possible.

Ideally it should happen as the first thing in Program.cs to be able to log initialization exceptions. Just think of the case where you start the web application on a port that's already taken. It's not possible to log this right now, right?

[lodejard]

It's a reasonable thing to do, resolving ILoggerProvider from IoC after ConfigureServices returns.

Though if you want the logging as soon as possible you'd still take ILoggerFactory as a Startup class constructor argument and add providers there. @cwe1ss that would log server startup exceptions also.

[cwe1ss]

I didn't know that this works! great, thx!

[muratg]

Does aspnet/Hosting#661 resolve this?