-
Notifications
You must be signed in to change notification settings - Fork 312
Proposal: Support IServiceProviderFactory #829
Comments
Will there be any consequences for those who despise the vile and dreaded public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.ConfigureServices(services =>
{
...
})
.Configure((app) =>
{
...
})
.Build();
host.Run();
} |
You can't replace the |
Fair enough ... just checking. Since I don't (with this pattern "can't" really), it won't affect me. 😄 |
How does it work if UseKestrel is already adding and accessing services? |
@Tratcher what specifically are you asking about? Passing the |
In the new IServiceProviderFactory. |
Works fine. Just like it does today. UseKestrel wires up an |
- A new abstraction that allows the DI container author to describe how to translate an IServiceCollection to a specific container and then to an IServiceProvider. - Hosting will use this abstraction to swap out the default container
Based on aspnet/DependencyInjection#442
The
WebHostBuilder
API would take advantage of this by using it as a way to override the defaultIServiceProvider
implementation without returning it directly from the application'sStartup
class. The wire up could look like this:One downside to this is that you don't get direct access to the container APIs in the
Startup
class (which is part of the benefit besides being able to swap out the default impl).In the above example,
UseAutofac
would wire up theIServiceProviderFactory
. We could also extend theConventionBasedStartup
to allow authoring aConfigureContainer
method that takes the concrete ContainerBuilder directly:The text was updated successfully, but these errors were encountered: