> as there’s also no definitive resource for a newcomer on what has changed that would make older documentation inaccurate.

The two pages you want are: https://docs.microsoft.com/en-us/aspnet/core/migration/50-to... and https://docs.microsoft.com/en-us/aspnet/core/migration/50-to...

Both should cover the majority of scenarios. The main takeaway is that everything you usually configure in `ConfigureServices` now hangs off `builder.Services`, and everything you'd configure in the middleware pipeline `Configure(IApplicationBuilder app)` is available after you call `var app = builder.Build();`.

I'll note that the change to the Minimal API was only in the project templates, so the old model does continue to work without any breaking changes.

Thank you for this. That first one in particular is probably exactly what I needed.

I guess the one downside of having lots of documentation (and third party guides/tutorials) is that it may take some time to update when there are significant changes

Is there an up-to-date guide for migrating from .NET Framework 4.8 to .NET Core 6.0 (or whatever the latest LTS is)? I guess many projects have not yet migrated, especially libraries that wanted to stay compatible.

.NET 3.5 SP1 support ends Jan 9, 2029. For .NET 4.8 there currently there is no support end date. Don't think it's gonna be sooner than 3.5.

> .NET Framework 4.8 is the latest version of .NET Framework and will continue to be distributed with future releases of Windows. As long as it is installed on a supported version of Windows, .NET Framework 4.8 will continue to also be supported. https://dotnet.microsoft.com/en-us/platform/support/policy/d...

I think for new apps, you should choose .NET Core. But for legacy apps, I suppose you can take your time. .NET Core actually has much shorter LTS lifecycle. Only 3 years: https://dotnet.microsoft.com/en-us/platform/support/policy/d...

In our case, a fairly big monolith .NET 4.8 web app is being migrated to .NET Core by splitting that monolith into microservices that run on .NET Core. Can't say if it is for better or worse, more moving parts in infrastructure for sure.

Put the API behind a gateway and migrate the modules to the .net core API.

( Doing something similar, but I'm not going to go with Microservices)

It really depends on your project & how your code is split up. A lot of business type logic code should be identical.

I've migrated a couple decade plus old web form projects. A lot of the business logic can be moved to .NET Core 6 verbatim. I'll often set up a new version & slowly proxy web requests from the old site to a new version of the site as we update it.

Upgrading usually requires an enormous amount of remediation work before it's even possible. Generally you can do it like this - convert to PackageReference style NuGet packages (this one alone may even be a blocker if you have certain unfortunate dependencies which aren't compatible with PackageReference), upgrade all your dependencies to a netstandard2.x compatible version (this is often brutally difficult in a big system and you may have to replace certain dependencies outright), start swapping out DI / Logging etc with the netstandard equivalents found in .NET Core, create a new .NET Core solution file and try to compile your project to see what breaks and fix any remaining issues.

Having done this it does work, but it's fairly time consuming and for larger apps virtually impossible without massive buy-in from the business.

From my understanding, that's not really a migratable stack. Depending on what you're doing in 4.8 (aspx, wpf, aka windows only type stuff) there's not a direct migration. It's more of a re-write.

I think you are only kind of right. aspx is over 10 years old, you should have switched to .NET MVC already and then the difference to .NET Core is small. We rewrote some things at an earlier company and there mostly general things like auth and where to get querystring variables and similar that had changed.

If we look at WCF to REST (or gRPC) it is also mainly easy since it is some general configurations and infrastructure things that have changed but most of the business logic will work. So you have to rewrite but it might be quite easy. And doing this once every decade is not that strange. Also remember that most of the old things still work. You can stay on those tech stacks for another couple of years if you feel that is better for your organization.

WPF wasn't left behind. It's still supported in .NET 6, you don't have to rewrite anything. Windows Forms, too. Can you be more specific what you mean by aspx? ASP.NET is, of course, still supported.

https://docs.microsoft.com/en-us/dotnet/core/porting/net-fra...

Aspx is the file extension of Web Forms pages, which have no direct migration path to .net core/6.

Ah, of course. Thank you!

Most of the changes are not _breaking_. There are new ways to do things but the old still works. You can have both an api controller and a minimal api in the same application. I agree that it is hard to know which version a specific blog post or tutorials works for.

That's not true, there are a lot of breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/compatibility/6...

The problem is that Microsoft can never avoid the temptation to fix things that weren't that broken and leave it up to you to find the bugs later. Even a theoretical "non-breaking" change like adding some more constructors broke some of our code, previously, you could add ILoggerFactory really easily and it found a single default constructor in LoggerFactory and just worked. The new overloads cause most DI systems to look for the constructor with the most parameters, some of which are not available, and then fall over.

MS need a better system for updates, every version has brought us a lot of headache although I can't really see us using anything else, which would be an enormous amount of work.

I really don't understand the obsession the ASPNET team has with minimal APIs. I'm firmly in the camp of wanting things to be explicit rather than implicit, because it gets difficult to keep implicit conventions in your head as things shift and melt chasing the latest fashions.

I think the easy to get started techs such as node ate their lunch for so long they felt they had to appeal to that market.

A lot of the changes are aimed at making it easier for people to get started with Asp.Net, and most of those aren't breaking changes. Traditionally Asp.Net has had a lot of boilerplate around project setup and configuration, and things like minimal APIs aim to change that. The unfortunate side effect is that it adds more complexity (more ways to do the same thing) to the ecosystem, and the newer minimal approaches probably aren't what you're see used in the typical production project.

For sure. There has been a lot of pushback in the community from both sides of that issue. They wanted to reduce the boilerplate and make it cleaner to make simpler projects (with the goal of enabling microservice scenarios). But that moved some people's cheese from the standpoint of what the recommended path is. The problem is that there's a huge amount of very good documentation on the microsoft documentation site, but it's not organized in a way that makes it easy to find.