Revisit Controller discovery conventions

[rynowak]

We have a complicated set of rules for controller discovery that involve looking at names, names of base-classes, which assembly defines a class/base-class, and which assemblies are referenced from an assembly.

We should figure out if/how we can streamline these rules. Some questions to discuss:

Should we require you to register assemblies that we use for discovery?

Should we require the ...Controller suffix in all cases?

Do we need opt-out/opt-in attributes?

[rynowak]

A humble proposal:

• Options has a list of assemblies to look at - we pre-populate it with the 'main project'
• Controller suffix applies only to the class we're looking at (not to base-classes)
• Provide a [Controller] attribute that is "Inherited" - you can put it on your class or a base-class

This is identical to what we're already doing for View Components

RE: the list of assemblies approach, this is a break from legacy, but it comes with some advantages. Since the list of assemblies is explicit, you have obvious control if you want to do something different. This is better for security since we're not going to have any risk of looking in strange places and finding things that match the naming convention. This is better for multi-tenancy since there's an obvious way to filter what's eligible for use in a given MVC instance. It also allows us to build more powerful things around componentization (auto-discovery of embedded view assets), which is a super common feature request.

Additionally, we could pre-populate the list with all of the assemblies that reference MVC - assuming there is a library manager abstraction. That would invert the flow of the current code, but maintain its behavior and simplify the rules

/cc @Eilon

[danroth27]

Why would the attribute be inherited but not the suffix convention?

What would the experience be for project-to-project scenarios where my controllers are in a referenced project?

What would it look like if I have to use a common controller base time (ex from a package) for all of my controllers?

[rynowak]

Why would the attribute be inherited but not the suffix convention?

Putting the attribute on a type makes a strong statement about its identity and role in your app. Names are at best a heuristic (SqlTransactionController). You don't get to change the name of your base class (other than choosing not to inherit from it).

What would the experience be for project-to-project scenarios where my controllers are in a referenced project?

@lodejard and I both like the idea of having a 'list of assemblies' but having this list be populated by all assemblies in your app that reference MVC.

What would it look like if I have to use a common controller base time (ex from a package) for all of my controllers?

[Controller]
public abstract class MyBaseController
{
}