Improve async support on the startup path

There are a few places where we lack async support that result in people making blocking call. These are using during application startup.

• IAsyncStartupFilter - https://github.com/dotnet/aspnetcore/issues/5897
• Startup (ConfigureServicesAsync, ConfigureAsync)
• IHostBuilder.Configure*
• IConfiguration initial load (keyvault requires an async call)

[davidfowl]

Perform async init in async Task Main and pass any object-graph into to TStartup or ConfigureServices without resorting to static state.

That was fixed in .NET 5 with this overload of UseStartup which lets you create the instance. Now you can use closures and ctor arguments again.

If you need services passed into Startup then make another DI container because the container isn’t mutable and that isn’t going to change.

Also the new hosting model removes some of the Program.cs/Startup.cs boilerplate so passing state in closures is possible and in a top level async main method. It makes the whole thing easier.

Guaranteed eager initialization of certain singleton services (async or not) prior to ASP.NET Core handling any incoming request.

https://github.com/dotnet/runtime/issues/43149 go add your +1. It’s not happening for .NET 6 though. As for adding the bool the AddSingleton. That’s a problem because it needs to be agreed upon by the other DI authors but if you can get consensus we can move forward with that design or we’ll have to pick another one.

Support for configuring async factories on ServiceCollection.

I don’t know how we’d support any of this in reality. The problem with async factories is that you need async constructors to inject them into. It’s viral, which means GetService would need to either block or throw. It also means that async factories can have both sync and async dependencies but sync factories can’t depend on async things (or it’ll be a pit of failure). This means you can’t constructor inject an async service. In your example above, where does IMyPreauthenticatedHttpClient get resolved?

We’d also need GetServiceAsync (as you described above), but not the generic overloads, that could be an extension method you wrote. BuildServiceProviderAsync (as you also describe) and a new ServiceDescriptor that 3rd party container authors could implement.

Anyhow, thanks for the write up. Those are real concrete problems that are hard to solve.

PS: it would be interested to start a discussion on async DI and see what others think. I don’t know how you’d solve the constructor problem but maybe we will find some interesting solutions.

EDIT:

In general, you’d want to split your IO graph from your non IO graph because they have very different performance characteristics. You want to be doing all of the impure stuff on the outside, and not have IO scattered within the construction of your dependency graph.

[soenneker]

I’m definitely looking forward to this. Essentially everything underlying the application startup has or is moving to async, and making the startup path that way would improve the fluidity. Things like initializing a Service Bus listener, or connecting to KeyVault can’t even be done synchronously.

Hoping this gets in .NET 7