Feature gaps to make replace WebHostBuilder with HostBuilder

[davidfowl]

• [x] - Add support for IHostingStartup - https://github.com/aspnet/Hosting/issues/1403
• [x] - Add support for Startup
• [x] - Various extension methods that do ASP.NET Core specific wire up (see the inventory below)
• [x] - Support ASPNETCORE_ENVIRONMENT as an environment we look at for environment detection
• [x] - Adding an EventSource for Host.Start and Host.Stop events.

Some notes:

• IHostingStartup shouldn't be that problematic but we already have the interface for ASP.NET Core applications. Do we re-use the interface in the wrong namespace or do we make another one in the Extensions namespace (like we did for IApplicationLifetime and IHostingEnvironment)

• Startup cannot I repeat, cannot support dependency injection. We want to avoid multiple DI containers at all costs. This will be a breaking change for web applications but it seems like a good one to make. This raises questions on what the new generic host based templates would look like since we inject IConfiguration today.

  • We can also consider a softer approach where we only support the HostBuilderContext and nothing more.

  • Alternatively we could only support Startup in the WebHost specific extension to generic host and keep full parity with minor syntax change. This breaks a few things:

    • The final service provider isn't IHost.Services, services added in Startup are not visible in Program.

• We may need to deprecate IHostingEnvironment and IApplicationLifetime and rename those interfaces under the generic host abstractions. The current situation makes it really hard to migrate properly as those type names conflict with types in the AspNetCore namespace immediately.

Inventory of extension methods on IWebHostBuilder:

• CaptureStartupErrors
• Configure
• ConfigureKestrel
• UseHttpSys
• UseIIS
• UseIISIntegration
• UseKestrel
• UseServer
• UseShutdownTimeout
• UseSockets
• UseLibuv
• UseStartup
• PreferHostingUrls
• UseUrls
• UseWebRoot

3rd Party

• UseApplicationInsights
• UseSerilog
• UseHealthEndpoints (AppMetrics/AspNetCoreHealth)

Github Search https://github.com/search?l=C%23&p=4&q=IWebHostBuilder&type=Code

[tidyui]

Hi @davidfowl, regarding removing DI from Startup. I'm guessing a lot of stuff that goes on in peoples Startups is a mix of actually starting the application and warming up the application. Starting it usually doesn't require access to the DI container other that being able to register the different service needed in the DI container.

Wouldn't a clean approach be to split it into Startup & Warmup, where Startup only can register services in the DI and configure the application and Warmup can only get already registered services injected into. This approach should also play nicely with other non-web application scenarios using the same HostBuilder.

Anyway, just an idea from a non-microsoft dev :)

[thefringeninja]

I don't get it. You are already free to supply your own Startup and inject all the dependencies you want, using new.

[tidyui]

Maybe I misunderstood the initial description @thefringeninja, but I was under the assumption that @davidfowl wanted to prohibit usage and access to the DI container during Startup in the future.

[MattJeanes]

As you mention IConfiguration is commonly injected into the Startup at the moment after being configured by the Web host in the Program.cs, how do you antipicate this working after these changes?

[Tratcher]

IConfiguration can be made available without DI, the host has a direct reference to it. Go look at the IWebHost.Configure and ConfigureServices APIs we have today that have first class access to IHostingEnvironment, IConfiguration, etc..

[lsiddiquee]

Apologies for a naive question. Does this imply potentially prepping this for non aspnet core scenario? On a partially related note, just yesterday I was looking for template and boiler plate code to write a service which can potentially run as windows service and/or linux daemon.

[davidfowl]

@lsiddiquee yes it does.

[davidfowl]

Proof of concept here https://github.com/davidfowl/GenericHostPOC.

Here's a working application build on 2.1 with a different implementation of the WebHostBuilder (backed by generic host). This approach has very few caveats and it's the one I think we'll take.

Things that outright won't work:

• Injection into Startup beyond IConfiguration and IHostingEnvironment
• IStartup.ConfigureServices is completely broken since it wants to be terminal we added a new feature in 2.1 to allow decorating both ConfigureServices and ConfigureContainer. This is broken because today they are in the container itself, to make them work, we'd need them to not be part of the container but instead be fields on the WebHostBuilder.
• IStartup no longer works. IStartup is problematic because ConfigureServices returns an IServiceProvider and we need it to compose with the other calls to ConfigureServices. In the generic host world, the thing that creates the final IServiceProvider is the IServiceProviderFactory. We'll need to throw when we detect an IStartup.

Things that need to be ported:

• IHostingStartup
• TestServer

Beyond that everything seems to work.