'Host.CreateDefaultBuilder' vs 'WebApplication.CreateBuilder' API shape inconsistency

[julealgon]

Ever since "generic host" became a thing, the Host static class was introduced to be the "starting point" for building the host. However, AspNetCore has it's own abstraction on top of it via the WebApplication class which actually generates a different builder that relies on the original builder.

This design feels very disconnected: each of these 2 "builders" have different ways of configuring logging, services, etc: one uses configuration methods (the generic host), while the AspNet version relies on properties to expose the underlying builders.

Why have the teams not aligned on this and built a unified interface for hosting that also works for AspNetCore in a seamless way? Are there any discussions to eventually unify this and have project setup be consistent no matter the target use case? Why is the ConfigureWebHostDefaults not the default anymore, as that worked using the same standard generic host builder?

It makes no sense to me that if I have a Worker process where I then want to add HTTP API capabilities to, I'm forced to basically rewrite my entire setup code due to the shift from Host.CreateDefaultBuilder to WebApplication.CreateBuilder.

I see this is called "minimal hosting" from here:

• "Minimal hosting" for ASP.NET Core applications aspnetcore#30354

But why would it be specific to AspNetCore though... why not modify Hosting.Extensions itself to be "minimal by default" then?

@davidfowl would like to hear your thoughts on this since you were the one proposing the minimal hosting effort.

[davidfowl]

We moved away from the ceremony of a generic host in the default templates and to the scenario specific WebApplicationBuilder. The general idea was to move away from calbacks and move to linear code for configuring everything, this was part of .NET 6. In .NET 7, we added var builder = Host.CreateApplicationBuilder() as the backbone of WebApplication.CreateBuilder so we could have a smoother integration of the API styles (building the linear API on top of the callback API was error prone). As a result, we now have a similar pattern to WebApplicationBuilder for non-web scenarios:

Web

var builder = WebApplication.CreateBuilder();

builder.Logging.AddConsole();

builder.Services.AddOptions<MyOptions>().BindConfiguration("MyConfig");

builder.Services.AddHostedService<MyWorker>();

var app = builder.Build();

app.MapGet("/", () => "Hello World");

app.Run();

Non-Web

var builder = Host.CreateApplicationBuilder();

builder.Logging.AddConsole();

builder.Services.AddOptions<MyOptions>().BindConfiguration("MyConfig");

builder.Services.AddHostedService<MyWorker>();

var host = builder.Build();

host.Run();

The plan is the switch everything to this style, but the new hosting APIs in the generic host are missing the IHostBuilder interface. This means that extensions that wire up the IHostBuilder don't just work (serilog for example). We need to get the ecossytem to build for this new API or add the IHostBuilder interface as a shim property to hook up older APIs for it to be put into the worker template.

cc @eerhardt @halter73 @bradygaster

[julealgon]

Oh this is very interesting! I had not seen that Host.CreateApplicationBuilder() method before anywhere.

I really appreciate that you guys are already attempting to standardize the hosting logic across all app types. I'll give that method a shot in our own services over here.

Thanks for the prompt clarification David.

[julealgon]

I guess the only remaining inconsistency is the entry point being different right? WebApplication.Create... vs Host.Create....

I imagine the only way to get away from this would be to implement static extension methods... (or change to an instance again? but that would look weird).

With static extension method support, we could add an extension to Host so that this would work:

var builder = Host.CreateWebApplicationBuilder();

Would be dramatically more consistent than the current approach.

[scuba6388]

Any updates on exposing an IHostBuilder from HostApplicationBuilder? I see this is present on WebApplicationBuilder.

[halter73]

The work to implement the IHostBuilder shim has already been done here internally in order to support things like WebApplicationFactory and EF tooling. @andrewlock has a good blog post on how it works. Things have been moved around a little bit since WebApplicationBuilder was replatted from HostBuilder to HostApplicationBuilder, but the same idea remains.

We did consider implementing IHostBuilder when reviewing the initial HostApplicationBuilder API Proposal in .NET 7, but decided against it considering that some things supported by HostBuilder are not supported by HostApplicationBuilder like changing the application name and content root path. These things simply throw exceptions at startup, but they are the kinds of things methods targeting IHostBuilder often do.

Initially, we thought it would be best for methods that support HostApplicationBuilder should try targeting something more limited than IHostBuilder like IServiceCollection or IConfigurationBuilder. As you can see with the EventLogSettingsSetup in #68580, it's often possible to delay reading of things like the IHostEnvironment until later during service resolution.

However, we quickly came to realize that some methods really do need access a wider array of hosting configuration APIs before the host is built, so @eerhardt introduced IHostApplicationBuilder which is implemented by both HostApplicationBuilder and WebApplicationBuilder. When reviewing the IHostApplicationBuilder API Proposal, we debated again whether we shouldn't just expose an IHostBuilder property, but decided against it.

[ridingmower]

Hello please provide a clear upgrade/migration path / with samples while trying to upgrade to the latest. WebApplication.CreateBuilder does not let me setup and switch paths..

Tried both options, the docs got me confused

Option 1

  //// Configure the web host
  builder.WebHost.ConfigureWebHost(webBuilder =>
  {
      webBuilder.UseWebRoot("wwwroot");
      webBuilder.UseStaticWebAssets();
  });

---

option 2 build before setup

  // Build the web application
  var app = builder.Build();

  // Configure the web host
  app.Host.ConfigureWebHostDefaults(webBuilder =>
  {
      webBuilder.UseWebRoot("wwwroot");
      webBuilder.UseStaticWebAssets();
  });