Spec out implicit behaviors of the DI container and service collection

[davidfowl]

Here's a good starting point:

simpleinjector/SimpleInjector#41 (comment)

We should capture all of these in our specification tests.

/cc @lodejard @Eilon @pranavkm

[khellang]

That would be nice! 👍 Microsoft.Extensions.DependencyInjection.Specification.Tests is already a good starting point, but I still think there might be "undocumented" expected behaviors.

[dadhi]

May be not a right place, but it is quite explicit and exemplary how DryIoc setups DI adapter:

if (container.ScopeContext != null)
    throw new ArgumentException(
        "Adapted container uses ambient scope context which is not supported by AspNetCore DI.");

var adapter = container.With(rules => rules
    .With(FactoryMethod.ConstructorWithResolvableArguments)
    .WithFactorySelector(Rules.SelectLastRegisteredFactory())
    .WithTrackingDisposableTransients()
    .WithImplicitRootOpenScope());

[davidfowl]

@dadhi it's definitely the right place 😄

[Eilon]

Moving to backlog.

[tillig]

On the Autofac implementation we're definitely getting questions (as outlined in that SimpleInjector issue) about whether there's a guaranteed order of things coming back from enumerable/collection services. Here's the latest one.

Is there a prescribed (or required) order for enumerables returned from the service provider?

[PleasantD]

Out of curiosity, what parts of the ASP.NET Core framework explicitly depend on the DI container and registration system?

I know that the WebHostBuilder is responsible for creating the registration collection and provides services like IApplicationLifetime and IHostingEnvironment as injectable. But environment configuration is context and could be provided within the existing context objects (IApplicationBuilder and HttpContext).

MVC registers services. But does it need to? Does it still have factory classes for constructing controllers and views? It seems odd to me that to use a piece of middleware I need to remember to register it's services in a different location.

Having a single DI container does seem to provide a way to implicitly make middleware "DI friendly", but this too could be solved by providing a middleware factory and allowing middleware to be constructed via that, again bypassing the conforming container. In fact, Autofac provided this kind of middleware factory for OWIN.

[Eilon]

@halter73 can you respond to some of these questions?

[pranavkm]

AFAIK, IConfigureOptions \ OptionsManager is the only collection that we use as IEnumerable<T> but doesn't have any explicit ordering to it. Might be useful to figure out if we rely on the setups to be run in a specific order.