If you are using Autofac in your ASP.NET Core application then I recommend to update Autofac to version 4.6.1. This bugfix release brought a change how child scope handle additional registrations so that some errors like Cannot resolve parameter 'IOptionsFactory<KestrelServerOptions>' just disappear.
With additional registrations I mean the following:
var builder = new ContainerBuilder();
using (var container = builder.Build())
{
using (var childScope = container.BeginLifetimeScope(innerBuilder =>
{
// additional registration that are known by childScope only
innerBuilder.RegisterType<Foo>().AsSelf();
}))
{
...
}
}
When using a child scope during the setup of an ASP.NET Core application having Autofac 4.6.0 or lower then you had to use the IContainer (= root scope) itself or use a workaround to register MVC components. The first option is not recommended because a DI container should be considered as immutable. The second option could be confusing if you don’t know the internals of Autofac.
The second options looks like this:
public class Startup
{
public Startup(ILifetimeScope childScope)
{
_childScope = childScope;
}
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();
// All singleton are "rebased" to "aspNetScopeTag"
const string aspNetScopeTag = "AspNetScope";
_aspNetScope = _childScope.BeginLifetimeScope(aspNetScopeTag,
builder => builder.Populate(services, aspNetScopeTag));
return new AutofacServiceProvider(_aspNetScope);
}
...
}
With Autofac 4.6.1 you just call Populate without any confusing parameters like aspNetScopeTag.
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();
_aspNetScope = _childScope.BeginLifetimeScope(builder => builder.Populate(services));
return new AutofacServiceProvider(_aspNetScope);
}
Want to try it out? I have prepared 2 projects: AspNetCore2_Autofac460 and AspNetCore2_Autofac461 in my github repo. Download the sources and start the applications with dotnet run in the corresponding folder. The first one will raise an error the latter will start the web server successfully.
P.S.: Missing context? Why someone would want to provide its own DI container instead of using IServiceCollection and be done with it? Then read my blog post ASP.NET Core in production: Take back control of your web app or the follow-up post ASP.NET Core in production: Graceful shutdown and reacting to aborted requests.
