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.

Kostenloses Cheat Sheet zu ASP.NET Core API-Dokumentation mit Swagger

Sebastian Gingter zeigt Ihnen auf wenigen Seiten übersichtlich zusammengefasst, was Sie bei der Dokumentation Ihrer ASP.NET Core API wissen sollten.

Melden Sie sich kostenlos zu unserem Newsletter an, um das Cheat Sheet per E-Mail zu erhalten.

Related Articles

 | Pawel Gerr

If you register a type as a singleton then you expect just 1 instance of this type in your whole application. What you may not know is that ASP.NET Core is creating 2 instances of during building of the that may lead to 2 instance of your "singleton". This is the case if you…

Read article
 | Pawel Gerr

After several years of using the same Dependency Injection (DI) framework like Autofac you may have a good understanding how your components, implementing the interface IDisposable, are going to be disposed. With the nuget package Microsoft.Extensions.DependencyInjection the new…

Read article
 | Pawel Gerr

With the introduction of ASP.NET Core 3.0 the default JSON serializer has been changed from Newtonsoft.Json to System.Text.Json. For projects and libraries switching to the new JSON serializer this change means more performance and the opportunity to rewrite our . Serialization…

Read article