Update the Worker template to use Host.CreateApplicationBuilder

[eerhardt]

The callback approach that Host.CreateDefaultBuilder uses is no longer recommended going forward, and the programming model is no longer used in ASP.NET apps - it uses the WebApplication.CreateBuilder() API which is imperative, top-to-bottom programming. The Worker template should follow the same pattern.

Fix #43113

[ArminShoeibi]

Hi @eerhardt, I've got a burning question that's been on my mind. You know how with WebApplicationBuilder we have access to the Host property (ConfigureHostBuilder)? Well, I was wondering if there's an alternative way to achieve the same thing with HostApplicationBuilder because currently, we don't seem to have access to it. Any ideas?

[eerhardt]

You know how with WebApplicationBuilder we have access to the Host property (ConfigureHostBuilder)? Well, I was wondering if there's an alternative way to achieve the same thing with HostApplicationBuilder because currently, we don't seem to have access to it. Any ideas?

Can you describe more about why you want to get access to the Host property (ConfigureHostBuilder)? What is your scenario?

[davidfowl]

I've been thinking about our host plan more an more an I think it's incomplete. One of the primary reasons we have the IHostBuilder interface is so that libraries can target APIs against something that was implemented on any IHostBuilder implementation. This means that things like orlens or serilog could target the IHostBuilder and not have to reference anything web specific, but still have that show up.

We need to fix this with the new builder pattern.

[mitchdenny]

Common base interface on the builders?

[davidfowl]

Common base interface on the builders?

Yep.

[eerhardt]

so that libraries can target APIs against something that was implemented on any IHostBuilder implementation

I found 2 more places that only had IHostBuilder extensions instead of IServiceCollection extensions and logged issues for them:

• Add IServiceCollection extension methods to enable MassTransit MassTransit/MassTransit#4297
• Add IServiceCollection extension methods to enable Steeltoe SteeltoeOSS/Steeltoe#1123

The issue that I have with the existing IHostBuilder interface is that it is all callback based. It makes supporting the imperative model difficult (see dotnet/runtime#61634 and dotnet/runtime#61635. And all the adapter code we have to try to make the 2 programming models work together).

I would be OK with adding a new IHostApplicationBuilder that was based on the imperative model:

interface IHostApplicationBuilder
{
    IConfiguration Configuration { get; }  // can't be ConfigurationManager since that is in MS.Ext.Configuration and Hosting.Abstractions references Configuration.Abstractions. So need to pick between IConfiguration and IConfigurationBuilder
    IHostEnvironment Environment { get; }
    ILoggingBuilder Logging { get; }
    IServiceCollection Services { get; }

    IHost Build();
    void ConfigureContainer<TContainerBuilder>(IServiceProviderFactory<TContainerBuilder>factory, Action<TContainerBuilder>? configure = null) where TContainerBuilder: notnull;
}

Note that the existing HostApplicationBuilder doesn't expose a IDictionary<object, object> Properties { get; } property, but it looks like dotnet/orleans uses IHostBuilder.Properties. So we might want to consider adding that.

[davidfowl]

I would be OK with adding a new IHostApplicationBuilder that was based on the imperative model:

👍🏾 This gels with what I was thinking.

[eerhardt]

OK, I'll write up a proposal for that in dotnet/runtime next week.

[eerhardt]

I'm going to merge this in order to get this in for preview4. I'll get that api-proposal issue logged next week in dotnet/runtime.