How to resolve IOptions instance inside ConfigureServices?

Question

Is it possible to resolve an instance of IOptions<AppSettings> from the ConfigureServices method in Startup? The documentation explicitly says:

Don't use IOptions<TOptions> or IOptionsMonitor<TOptions> in Startup.ConfigureServices. An inconsistent options state may exist due to the ordering of service registrations.

You can manually create a service provider using serviceCollection.BuildServiceProvider() but this results in the warning:

Calling 'BuildServiceProvider' from application code results in an additional copy of singleton services being created. Consider alternatives such as dependency injecting services as parameters to 'Configure'.

How can I achieve this?

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<AppSettings>(
        configuration.GetConfigurationSection(nameof(AppSettings)));

    // How can I resolve IOptions<AppSettings> here?
}

Methaemoglobin

Check if you really need an IOptions<T> instance in your ConfigureServices first. If you only need T, Configuration.GetSection("section").Get<T>() may be enough (https://mcmap.net/q/65616/-how-to-resolve-ioptions-instance-inside-configureservices) You loose IOptions feature though (validation) – Googol

Answer 1

If you need to resolve service using the service provider manually you can use this AddSingleton/AddScoped/AddTransient overload:

// Works for AddScoped and AddTransient as well
services.AddSingleton<IBarService>(sp =>
{
    var fooService = sp.GetRequiredService<IFooService>();
    return new BarService(fooService);
}

If you really want to, you can build an intermediate service provider using the BuildServiceProvider() method on the IServiceCollection:

public void ConfigureService(IServiceCollection services)
{
    // Configure the services
    services.AddTransient<IFooService, FooServiceImpl>();
    services.Configure<AppSettings>(configuration.GetSection(nameof(AppSettings)));

    // Build an intermediate service provider
    var sp = services.BuildServiceProvider();

    // Resolve the services from the service provider
    var fooService = sp.GetService<IFooService>();
    var options = sp.GetService<IOptions<AppSettings>>();
}

You need the Microsoft.Extensions.DependencyInjection package for this.

However, please note that this results in multiple service provider instances which may in turn result in multiple singleton instances.

---

In the case where you just need to bind some options in ConfigureServices, you can also use the Bind method:

var appSettings = new AppSettings();
configuration.GetSection(nameof(AppSettings)).Bind(appSettings);

This functionality is available through the Microsoft.Extensions.Configuration.Binder package.

Catchall

What if you need to resolve this service in another part of the application? I'm sure it's not all done in ConfigureServices() right? – Livvi

@Livvi then you can use the default dependency injection mechanisms such as constructor injection. This question is specifically about resolving services inside the ConfigureServices method. – Catchall

@pcdev You get NULL when you do so and then try to resolve the instance. You have to add the service first. – Gain

@Gain yeah, sorry, that comment was incorrect and should be deleted - I didn't properly understand what was going on when I wrote that comment. Please see the answer I linked to previously which I've since updated - I did some more investigation and now understand it better. – Tusk

While this may be useful in cases where the method to add a service doesn't have an implementation factory overload (e.g., here), using BuildServiceProvider causes a warning if used in application code such as ConfigureServices as it results in an additional copy of singleton services being created. Ehsan Mirsaeedi's answer here is the most ideal solution for cases like this. – Nitriding

This answer is wrong as if there is any singleton registration, it may lead to create several times the singleton. @ehsan-mirsaeedi answer is better and should be the accepted answer. – Wakerly

@HenkMollema please either delete this answer or revise it based on the feedback above. This answer is not correct and will result in warnings + double singleton registration. – Wynnie

I get an error: Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetService<T>(...) returned null. – Locarno

I've updated the answer with a warning about the duplicate service provider side-effect and an alternative solution. – Catchall

@Locarno if GetService<T> returns null it means that the service is not (properly) registered. – Catchall

This answer is dangerous because it's wrong. – Ascidian

Answer 2

The best way for instantiating classes that are dependent on other services is to use the AddXXX overload that provides you with the IServiceProvider. This way you do not need to instantiate an intermediate service provider.

The following samples show how you can use this overload in AddSingleton/AddTransient methods.

services.AddSingleton(serviceProvider =>
{
    var options = serviceProvider.GetService<IOptions<AppSettings>>();
    var foo = new Foo(options);
    return foo ;
});


services.AddTransient(serviceProvider =>
{
    var options = serviceProvider.GetService<IOptions<AppSettings>>();
    var bar = new Bar(options);
    return bar;
});

Portillo

Use this solution rather than the accepted answer for .Net Core 3 or higher! – Duodecillion

@Duodecillion I am not so sure that this is a viable replacement for the accepted answer in all scenarios. IServiceProvider is available for i.e. AddSingleton, AddScoped, AddTransient. But there are many other Add methods that do not provide this overload, i.e. AddCors, AddAuthentication, AddAuthorization. – Roaring

@Roaring You mix up things unrelated. AddCors, AddAuthentication and so on are helpers that call underneath the registration emthods to wire up the various underlying middleware. AddTransient, AddSingleton, AddScoped are the three registrations (with the three commonly used lifetimes) – Wakerly

This does not cover all cases. Please refer to my answer for a solution that does. – Ascidian

I think these inner lamdas are running async or on some other timing. We had the BuildServiceProvider approach and I wanted to eliminate the build warning so I shifted to this approach. Now I am seeing some side effects for things where timing matters (AddIdentity vs. ConfigureApplicationCookie) – Lamaism

@ChrisBaker Which is exactly why you shouldn't be building service providers yourself, and why my answer is the only correct one here! – Ascidian

Working in .NET 6, I was trying to use it this way Options.Create(serviceProvider.GetService(AppSettings) but changing it to serviceProvider.GetService<IOptions<AppSettings>> fixed the issue for me. – Unintelligent

Answer 3

All of the other answers telling you to manually build an IServiceProvider to get an IOptions<T> instance are dangerous because they are wrong (at least as of ASP.NET Core 3.0)! In fact, if you use those answers today, you will get the following compiler warning:

Calling 'BuildServiceProvider' from application code results in an additional copy of singleton services being created. Consider alternatives such as dependency injecting services as parameters to 'Configure'.

The correct way is to accomplish this, which works safely and reliably in all versions of ASP.NET Core, is to implement the IConfigureOptions<TOptions> interface that's existed since .NET Core 1.0 - but it seems that far too few people know about how it makes things Just Work™.

As an example, you want to add a custom model validator that has a dependency on one of your application's other services. Initially it seems impossible - there's no way to resolve IMyServiceDependency because you have no access to an IServiceProvider:

public class MyModelValidatorProvider : IModelValidatorProvider
{
    public MyModelValidatorProvider(IMyServiceDependency dependency)
    {
        ...
    }
}

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers(options =>
    {
        options.ModelValidatorProviders.Add(new MyModelValidatorProvider(??????));
    });
}

But the "magic" of IConfigureOptions<TOptions> makes it so easy:

public class ConfigureMvcOptions : IConfigureOptions<MvcOptions>
{
    private IMyServiceDependency _dependency;

    public MyMvcOptions(IMyServiceDependency dependency)
        => _dependency = dependency;

    public void Configure(MvcOptions options)
        => options.ModelValidatorProviders.Add(new MyModelValidatorProvider(_dependency));
}

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

    ...

    // or scoped, or transient, as necessary for your service
    services.AddSingleton<IConfigureOptions<MvcOptions>, ConfigureMvcOptions>();
}

Essentially, any setup you would have done in the Add***(***Options) delegates in ConfigureServices is now moved to your IConfigureOptions<TOptions> class's Configure method. Then you register the options in the same way you'd register any other service, and away you go!

For more detail, as well as information on how this works behind the scenes, I refer you to the always-excellent Andrew Lock.

Ascidian

What if you only need a configuration object to read while calling other library's extension methods? Is there any way to render/resolve configuration to inform values you provide while registering other services? – Arc

@AlexanderTrauzzi just pass IConfiguration into ConfigureServices - IOC will provide it. – Stockbroker

Any way around that as a library author, given that it'll be in an extension method? – Arc

@AlexanderTrauzzi I suggest you ask a question detailing what you're trying to accomplish. – Ascidian

Let's say you use this approach to configure MvcOptions, but you also configure it the normal way. Does your way "add" to the existing config, or "replace" it? – Tuckerbag

Answer 4

In addition to @henkmollema answer you can use the Get method directly on IConfiguration, e.g.

public void ConfigureServices(IServiceCollection services)
{
    var iConf=configuration.GetSection(nameof(AppSettings));

    services.Configure<AppSettings>(iConf);

    // How can I resolve IOptions<AppSettings> here?
    var opts=iConf.Get<AppSettings>();
}

Note: in this way you are getting directly AppSettings and not IOptions<AppSettings>.

Worse

Answer 5

Are you looking for something like following? You can take a look at my comments in the code:

// this call would new-up `AppSettings` type
services.Configure<AppSettings>(appSettings =>
{
    // bind the newed-up type with the data from the configuration section
    ConfigurationBinder.Bind(appSettings, Configuration.GetConfigurationSection(nameof(AppSettings)));

    // modify these settings if you want to
});

// your updated app settings should be available through DI now

Garneau

Answer 6

Want to help others who look the same thing but when using Autofac too.

If you want to get ILifetimeScope (i.e. container of current scope) you need to call app.ApplicationServices.GetAutofacRoot() method in Configure(IApplicationBuilder app) this will return ILifetimeScope instance you can use to resolve services

public void Configure(IApplicationBuilder app)
    {
        //app middleware registrations 
        //...
        //

        ILifetimeScope autofacRoot = app.ApplicationServices.GetAutofacRoot();
        var repository = autofacRoot.Resolve<IRepository>();
    }

Adalbert

This answer is too specfic to AutoFac, which is not in the scope of this question. – Fisher

I came here by googling this question with autofac prefix and didn't find any specific topic unfortunately. So I expect that others who will also come to this question struggling with this problem can find an answer. – Adalbert

Answer 7

In MVC Core 3.1 or .Net 5, you can pass in the IOptions to services in Startup.cs in two lines:

Your IOptions settings registration first:

services.Configure<MySettings>(Configuration.GetSection("MySection"));

Then your service registration, passing in the IOptions:

services.AddSingleton<IMyService, MyService>(x => new MyService(x.GetService<IOptions<MySettings>>()));

Inconceivable

How is this different from the accepted answer? – Ascidian

@Ian Kemp - The accepted answer is detailed with a great explanation but I couldn't get my code to work with it. My answer is just another addition to the myriad answers also given. I have found nuances in the various MVC frameworks and have implied how I pass options via DI for MVC Core 3.1 or .Net 5. It may help someone. When I've used Stackoverflow, I have generally found the specific answer to my problem or a code snippet from the other answers given not always the accepted answer. So it helps to have more answers with different examples even if they are similar to the accepted answer. – Inconceivable