ControllerActivator should be able to use controllers registered as services

[danroth27]

Something like:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc().WithControllersFromDI();
    }
}

This would replace the default activator with one that gets the controllers from DI.
This replaces #1700
CC @lodejard @davidfowl @halter73 @pranavkm @yishaigalatzer

[danroth27]

We think we can do this without the additional extension method.

[pranavkm]

Based on discussion with @lodejard \ @yishaigalatzer

1. Move the code that currently exists in the DefaultControllerActivator into the DefaultControllerFactory.
2. Change the signature of the IControllerActivator to have a method public object Activate(ActionContext context). When WithControllersFromDI is invoked, we'll replace the default TypeActivatedControllerActivator with ServiceBasedControlActivator that creates controllers from the service provider.
3. Remove use of ITypeActivator in TypeActivatedControllerActivator and use the static activator method instead.

[pranavkm]

Additional requirements:

During controller discovery, controller types in the application that are not registered in the service container should not be considered as controllers. The intent is to

1. Use registration as a way to determine which controllers are available for an instance of the Mvc application.
2. Ensure that accessing controller that are not registered result in 404 and not a 500 (due to GetRequiredService throwing).

Implementation design:

• Introduce a type (ServiceProviderControllerRegistration?) that allow registration of controller types. As part of registering a controller as a service, controllers must be additionally registered with this type.
• Introduce IControllerProvider that will be consumed by the ControllerModelBuilder. In the default case, IControllerProvider will perform the scanning of controllers. This code exists in the DefaultControllerModelBuilder today.
• ServiceBasedControllerProvider will be an additional implementation of IControllerProvider that will use the controller registration to produce a sequence of controllers that the application will use.

Usage:

services.AddMvc()
             .WithControllersFromDI()
             .RegisterController(typeof(FooController))
             .RegisterController<QuxController>()
             .RegisterControllers(new[] { typeof(BarController), typeof(BazController) });

[avanderhoorn]

Just wondering, why was this implemented the way that it is instead of tapping into the options system? Meaning why do we have FixedSetControllerTypeProvider which has its collection populated via WithControllersAsServices instead of it being like the other "Default" providers, and have a Controllers property on MvcOptions which it pulls in the values from. Where was the semantic line in the sand?

My only thought is that you were trying to make it more explicit and if it was on MvcOptions the property would sometimes be used and not others (depending on whether the FixedSetControllerTypeProvider was being used vs the DefaultControllerTypeProvider).

[yishaigalatzer]

That's a good question. It's mostly because the controllers list is computed as late as possible, and options typically have specific types rather than providers. Honestly this could have gone both ways.

[avanderhoorn]

@yishaigalatzer Thanks for filling me in. I was just confused when I saw two different strategies for doing very similar things.