Why migrate to the ASP.NET Core 6 minimal hosting model?

Question

I'm upgrading a system from ASP.NET Core 5 to 6. I've read the migration guide for the new "minimal hosting model".

The docs say the new way is preferred and recommended, but the old way is supported - so I don't need to change. They also state the old way is useful for "advanced" scenarios, without mentioning details.

There's lots of docs / blogs / SO questions about how to use the new way - but no mention of why. An "app in just four lines" is given as a reason, but that is insufficient cause to migrate a working system.

I'll upgrade to v6, but am undecided about the hosting model. How would I or my working production system benefit?

If you migrated a production system to the new hosting model, would you please share advice about whether it was worth it? What are the pros (and cons) of the new approach? Thanks!

Mejias

The page lists advantages that only apply to small projects, I don't see anywhere it says it's "recommended" as a blanket-statement. – Schema

I took a closer look... I do admit that in the FAQ it does say "However, we recommend apps migrate to the new hosting model to take advantage of new features only available to the new hosting model." - but the only advantages listed so far (at the start of the document) don't sound like real advantages to me... – Schema

@Schema Exactly. I like the new model, it feels like Node/Express. If I were to start a new project, or were new to the .NET world, I'd use the new way. But I don't see advantages for existing systems - maybe I lack imagination, that's why I'm asking here for guidance. – Mejias

Not sure what ASP.NET Core apps Microsoft are working on but, Unifies Startup.cs and Program.cs into a single Program.cs file., that's a disadvantage. In my case, I use a mix of the new hosting model (in Program.cs) with an existing Startup class that does the bootstrapping. This allows me to use packages such as FastEndpoints and other features that are available to the new interface. – Amata

Any statement of recommendation indicates that Microsoft has decided to move on that direction, so staying on the old way (examples, VB6, classic ASP, WebForms, .NET Framework) is of course supported but what you lose is more and more new things. – Hinge

It definitely wasn't marketing if you're looking for somebody to blame, blame the team, we decided. – Kikelia

@Kikelia Lol, not looking to blame anyone. The new model feels very Express-ish. I like it, I just never found an explanation anywhere about why I should use it... (docs targetted new apps and new devs). I like all the simplifications and improvements your team has been making in the last few years, congratulations are in order! :-) – Mejias

I found an @andrewlock blog post helpful in understanding the changes for existing systems, and a davidfowl migration cheatsheet to be very helpful, with before/after examples. – Mejias

@Amata As an aside, thanks for telling me about FastEndpoints! It looks very good. Do you use it for work in a production environment? Do you recommend it? – Mejias

@Mejias You're welcome! I'm using it in a personal project currently, not in a work environment. It's quite good and lightweight for what it is and, for microservices, it strips away quite a lot of the Controller overhead. – Amata

Answer 1

The biggest change with the new hosting model is a style change. The callbacks on IHostBuilder have been change to a more straight line model (instead of adding callbacks and then building the host, it's write code to configure then build the host). That allows you to get in between initialization and write imperative logic. One of the bigger ways this shows up is async initialization. You can just write code that await some asynchronous configuration, then use the result of that to add a service. This is really hard to do with callbacks since we're need to add async Configure/ConfigureServices and many other things. This model just lets you write code.

The sample in the migration guide that shows how to keep the Startup class but still use the new WebApplicationBuilder illustrates this best:

using Microsoft.AspNetCore.Builder;

var builder = WebApplication.CreateBuilder(args);

var startup = new Startup(builder.Configuration);

startup.ConfigureServices(builder.Services);

var app = builder.Build();

startup.Configure(app, app.Environment);

app.Run();

It's extremely clear an obvious when these methods are being called and how Startup is constructed.

In the end, it's really a pattern change where you might not see a huge benefit if you have already fully understand and programming around the existing model. That's why it's optional.

Kikelia

"It's extremely clear an obvious when these methods are being called and how Startup is constructed." - kinda, but it's not obvious where/if app (which is IDisposable) is ever disposed, for example. If Run disposes of itself then the documentation for that doesn't mention it. Also, the Main method in top-level statement code is async, so why is Run() used instead of await RunAsync()? – Schema

We chose to leave it sync. There's no real benefit to making it async. We also wanted to remove keywords for the default scenario. Blocking main is fine. The nice thing about top level statements is that you any await will make main async so it doesn't matter. – Kikelia

An answer from the horse's mouth... so it's appreciated! It looks and feels very much like Express, so it felt like it didn't add anything other than a style change (for existing apps) - that was not meant as an insult, I like Express. Your explanation make sense. I haven't used it yet, but it seems the new model will make future changes easier as there are less moving parts, and simplifies customisation as well, which is nice. – Mejias

What about using class libraries that hook into early startup - the UseXYZ libraries that we would register in Program.cs. Is that still supported, or do we fall back to the old model in such cases? – Mejias

This document has everything you should need learn.microsoft.com/en-us/aspnet/core/fundamentals/…. The WebHost and Host hang off as properties for existing extension methods. – Kikelia

Thanks. I also found this gist of yours - the before/after sections are really helpful! – Mejias