Hacker News Reader

Comment by Hawxy | Hacker News Reader

> 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.

View on HN

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.

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!

.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.

Reply on news.ycombinator.com