Add support for executing IHostingStartup in the app assembly

[danroth27]

There isn't a good way today for tooling to be able to enable features in an ASP.NET Core app (services, config providers, etc.) without having to parse user code. If we added support for executing IHostingStartup implementations that are within the app then tooling could add this kind of functionality by adding a code file with a class implementation to the project. For example, you could have a tooling gesture that sets up the Azure Key Vault config provider for you.

[Tratcher]

What's missing, the discovery? It should work if VS sets the env variable to the app assembly name.

[danroth27]

For IHostingStartup implementations in the app assembly I think it should work without needing the environment variable. For tooling scenarios you often want to light up features in the app that aren't environmental. For example, I still want to use the key vault config provider even when I'm not running in VS.

[danroth27]

@DamianEdwards @davidfowl @muratg

This could also be useful for configuring authentication given the changed coming to the authentication abstractions.

[danroth27]

@DamianEdwards and @davidfowl chatted and agreed we should do this for 2.0.0. We would look for the assembly level attributes in the app by default with an option to turn it off.

@muratg Please assign

[Tratcher]

The existence of a single app assembly is a poor architectural assumption that developers keep breaking. E.g. they move controllers or views to a second assembly and they no longer work. We need something that accounts for multi-assembly apps.

[danroth27]

Some options:

1. Only scan the app assembly
2. Scan every assembly in the graph
3. Scan a list of assemblies specified by the user where the app assembly is in the list by default

If we did 2 then I think you might need a way to exclude stuff.

I lean towards 3. Thoughts?

[DamianEdwards]

3 seems reasonable to me

[davidfowl]

We're not scanning every assembly in the graph by default in hosting 😄.

The existence of a single app assembly is a poor architectural assumption that developers keep breaking. E.g. they move controllers or views to a second assembly and they no longer work. We need something that accounts for multi-assembly apps.

I'm going to say no, this feature isn't for those people. It's not a plugin mechanism for libraries. Scanning only the app assembly IMO makes the most sense. We can wait to get more feedback to do anything else.

[Tratcher]

Note: We'll do this by prepending IHostingEnvironment.ApplicationName to HostingStartupAssemblies

[chuanboz]

Do we have this interface in the generic host? I only find it in the WebHost.