Question: AddOptions<T>() vs. Multiple Configure<T>(…)

I’ve been writing code like the following in my projects in Startup.cs:

// this is from ConfigureServices, so services is an instance of IServiceCollection
// assume Configuration is an instance of IConfiguration and was injected via the constructor
services.AddOptions()
  .Configure<MyOptions>(Configuration.GetSection("mySection"))
  .Configure<MyOptions>(x => x.SomeProperty = "foo");

and i’m wondering if I should expect this to continue working, or if it is just coincidence and I should switch to the following:

services.AddOptions()
  .AddOptions<MyOptions>()
  .Bind(Configuration.GetSection("mySection"))
  .Configure(x => x.SomeProperty = "foo");

Some more context: the reason i’m asking this is because i see that in the first example both of those Configure<TOptions>(…) methods use services.AddSingleton<IConfigureOptions<TOptions>>(…) under the hood, and – although each uses a different type for the implementation instance – i was under the impression that the number of registrations for a service type is restricted to one, either by ServiceCollection or ServiceProvider

[poke]

Configure<TOptions>(Action<TOptions> configureOptions) and OptionsBuilder<TOptions>.Configure(Action<TOptions> configureOptions) will both end up doing the same thing:

services.AddSingleton<IConfigureOptions<TOptions>>(
    new ConfigureNamedOptions<TOptions>(name, configureOptions));

And OptionsBuilder<TOptions>.Bind(IConfiguration config) will actually call Configure<TOptions>(IConfiguration config) directly, so they are also equivalent.

So both APIs are interchangeable. And you can expect the services.Configure calls to continue to work. The options builder API came later to allow for a bit more control with various utility methods. But it’s not a replacement for the direct services.Configure API.

I was under the impression that the number of registrations for a service type is restricted to one

No, you can register any number of implementations for the same service type. While it is true that the normal service resolution will only give you a single instance, which will then be the latest registered dependency for that type, the options framework will resolve an IEnumerable<IConfigureOptions<TOptions>> which will make the DI container provide all registered implementations for that type. So the framework can then work through them in order and apply all registered configuration sources on the options object.

[poke]

Hmm, I’m not too sure about other implementations and how much of that behavior is required by IServiceProvider. I think what is true for all DI containers is that the last registration wins. So when you inject T, then the last registration for T will be what you get. This is to allow overwriting registrations.

Some containers may then choose not to make multiple registrations for T available as IEnumerable<T>. I think SimpleInjector does not do this; there, you have to register the collection individually.

But since ASP.NET Core requires this behavior for some of the things to work, I would assume that you can expect this to work for all DI containers that integrate with ASP.NET Core.