Proposal: Add IServiceProviderFactory

[davidfowl]

This will allow 3rd party containers to plug into the default pipeline when the application doesn't:

public interface IServiceProviderFactory<TContainerBuilder>
{
    TContainerBuilder CreateContainerBuilder(IServiceCollection services);
    IServiceProvider CreateServiceProvider(TContainerBuilder containerBuilder);
}

public class ExampleAutofacServiceProviderFactory : IServiceProviderFactory<ContainerBuilder>
{
    public override ContainerBuilder CreateContainerBuilder(IServiceCollection services)
    {
         var containerBuilder = new ContainerBuilder();
         containerBuilder.Populate(services);
         return containerBuilder;
     }

    public override IServiceProvider CreateServiceProvider(ContainerBuilder containerBuilder)
    {
        return new AutofacServiceProvider(containerBuilder.Build());
    }
}

See aspnet/Hosting#829 for consumption

/cc @tillig @khellang

[khellang]

I like it! Reminds me a bit of some of the things I did with the Nancy bootstrapper prototype. This would cut down on the amount of code someone would have to write when you just want to use a third party container, but don't care about its registration APIs. You could question the need for a third party container in this case, though... But it looks like a nice addition.

[tillig]

I like it, particularly in combination with the ConfigureServices overload. Getting a ContainerBuilder (or whatever your container takes) right into the method would save a lot of boilerplate (stuff I actually have in a few projects already).

[davidfowl]

You could question the need for a third party container in this case, though... But it looks like a nice addition.

Yea, that's why paired with the ConfigureContainer(TContainer container) approach, it might be pretty nice.

It would be great to get some more feedback here to see if this is a viable approach. We plan to use this ourselves to test out our system with different DI containers.

[davidfowl]

I wonder if this should just be a hosting specific interface. To hang extension methods off the IWebHost you'd need to reference Hosting.Abstractions anyways. It'll matter more if other systems decide to use this interface for wire up.

[khellang]

I wonder if this should just be a hosting specific interface. To hang extension methods off the IWebHost you'd need to reference Hosting.Abstractions anyways.

Makes sense to split out a separate package, then. Something like StructureMap.AspNetCore.DependencyInjection (in the StructureMap case), to contrast StructureMap.Microsoft.DependencyInjection 😄

Yea, that's why paired with the ConfigureContainer(TContainer container) approach, it might be pretty nice.

Do I smell an extension to IStartup and family as well?

[davidfowl]

/cc @ipjohnson @dadhi @seesharper

[dadhi]

Does it mean, that implementation of provider is supposed to be based on "normal" adapter with it Populate method?

[ipjohnson]

I like it a lot as well, especially being able to provide container specific extension that allows for configuration.

@davidfowl what do you see as the time frame for us to create providers? Should we start planning to create packages soon or a couple months down the road (I see 1.1.0 but not sure how far off that is)?

[davidfowl]

Does it mean, that implementation of provider is supposed to be based on "normal" adapter with it Populate method?

It's the container after the populate call.

@davidfowl what do you see as the time frame for us to create providers? Should we start planning to create packages soon or a couple months down the road (I see 1.1.0 but not sure how far off that is)?

@DamianEdwards roadmap for 1.1?

[davidfowl]

I've commited the DI side of things. Will push the Hosting changes tomorrow.