Consider exposing IConfiguration from IHostBuilder

[MV10]

Calling Host.CreateDefaultBuilder automatically builds IConfiguration with a number of useful, very standardized rules. However, that configuration information is only available from HostBuilderContext via delegate-consuming config methods like ConfigureServices lambdas.

It would be useful if that configuration information was available either directly from IHostBuilder (or perhaps IHostBuilderContext could be exposed instead). I have scenarios where I need to call asynchronous methods during startup which require configuration information. I've run across this building a variety of different types of applications, such as those that run on Azure (for example, Key Vault calls are async), building Orleans apps (connect a cluster-client and register it for injection), various database calls during startup, and so on. I suppose this is the same reason everyone wishes we had async config methods in ASP.NET Startup.cs.

Currently I'm "stealing" a reference to configuration with a dummy call to ConfigureServices:

IConfiguration config = null;
hostBuilder.ConfigureServices((ctx, svc) => config = ctx.Configuration );
var client = await ConnectAsync(config);

It works, but it's pretty clearly a hack. I can't put the async call inside the lambda for a less hacky approach because void-returning async lambdas can't be awaited:

// no Task on this Action<>...
hostBuilder.ConfigureServices(async (ctx, svc) =>
{
    // ...without a Task, this won't actually await:
    var client = await ConnectAsync(ctx.Configuration);
});

[greggwon]

Ultimately, all this injection just really cripples construction of services and "the app" around the fact that there is so much context wrapped into how all of this is strung together. Too much is hidden inside that is not instantly accessible. The Builder series of interfaces should really be properties of an "AppInstance" implementation so that you can extend that class/interface in your class, and then just have everything as local to that instance methods. This feels too much like a bunch of Javascript programmers who don't understand why typescript exists created all this trying to make as many types as possible disappear and become "referenced by intent" instead of "visible for intended use".

[maryamariyan]

Closing since we're working on improving this workflow with issue #61634