> The writing was on the wall a long, long time ago! [...] These companies had 15 years to do it.

I pointed this out in 2013 only to be literally shouted down by my manager. I did so again in 2017 under a different manager on the same team with the suggestion that we investigate using SPAs and RESTful frameworks only to be told that Razor Pages was the way forward which, while an improvement, didn't do any wonders for our ability to attract/build technical talent or create rich user experiences.

As a sibling comment points out (in a sentiment that I've echoed on HN before):

> ASP.NET Web Forms are a complete trainwreck and an abuse of HTTP and other basic web development standards (e.g. by using javascript: URLs and POSTing forms for every single interaction with the page). It is broken by design.

You can probably see why developers that chose this framework in the first place aren't interested in upgrading... learning actual web standards and state management isn't something they wanted to do in the first place.

> You can probably see why developers that chose this framework in the first place aren't interested in upgrading... learning actual web standards and state management isn't something they wanted to do in the first place.

This is why I'm personally extremely skeptical of both Razor Pages and all of Blazor (Client, Server, Unified, whatever). All of that feels a lot like "Web Forms Again, this time with more C#" to me. Parts of Blazor especially may as well be ASP Classic `runat="server"` and look just like it to me. It kind of feels like a lot of ASP developers have already forgotten the hard problems of ASP Classic and ASP.NET Web Forms and have been doomed to recreate them cyclically.

Classic management f**-up. Some products/companies just die, because of bad management that doesn’t react to change. Get a new job ;)

> Get a new job ;)

Done :-).

> Some products/companies just die, because of bad management that doesn’t react to change

Some don't have to because they get paid no matter what.

Sure, but at some point the last sane developer either quits or retires, and then they are completely f*ed.

15 years of management experience. Oversaw the reduction of personnel expenditures by 90%. They'll do fine.

> The writing was on the wall a long, long time ago!

The vast majority of ASP.NET Web Apps could not have migrated to .NET Core 1.0, it was missing too many features. It was missing types like 'securestring', and had zero support for Workflow Foundation, Windows Communication Foundation, etc...

At the time, .NET Core was also advertised as "an alternative platform for Linux apps", not as a direct replacement for .NET Framework.

It was only in .NET 5 that Microsoft changes their tune and started calling Core the "replacement". At the time, something like half of complex enterprise apps might be able to migrate across, but they would have encountered a long list of breaking issues with a note saying "we might fix that in an upcoming major release". That's after a partial rewrite.

You can't go to a business that has a web app that's "not broken" and suggest migrating it to a definitely broken platform that's very much still playing "catch up".

Support is improving in .NET 7, and the upcoming .NET 8, but it's definitely not 100% and pretending that it's the "end users' fault" for not jumping onto an incomplete and buggy platform is not helpful.

I'll list some random GitHub issues for you to perouse. For large enterprise apps, many of these are showstoppers for incremental or seamless migrations. The workaround is always "rewrite everything from scratch using wildly different technologies that aren't direct replacements."

    IIS app pool recycle throws 503 errors
    https://github.com/dotnet/aspnetcore/issues/41340

    OData core libraries now support OData v4 
    https://devblogs.microsoft.com/odata/announcement-odata-core-libraries-now-support-odata-v4/
    (.NET Framework is v1-v3, and Core is 4.0+, a breaking change!)

    Workflow Foundation didn't start getting migrated until .NET 6, and not by Microsoft!
    https://github.com/UiPath/corewf

    dotnet-svcutil ignores most of the settings
    https://github.com/dotnet/wcf/issues/4887

    dotnet-svcutil silently failing to deserialize responses
    https://github.com/dotnet/wcf/issues/4163

    Reuse of Types not working with WCF dotnet-svcutil tool for .NET Core
    https://github.com/dotnet/wcf/issues/4277

    Visual Studio 16.8 breaks SvcUtil build targets
    https://github.com/dotnet/wcf/issues/4431

I wasn't saying anything about .Net Core 1.0, I was talking about MVC 1, 2, 3, 4 or 5 that came out 15 years ago. I meant any sane business should have migrated away from webforms before Core even came out.

By MVC 3, which was 2011, it was bloody obvious webforms were not the future of .Net web development.

And you could run both in the same project with a small bit of effort.

Here's a Scott Gu post from 2009 saying so:

ASP.NET 4.0 makes it easy to implement clean, SEO friendly, URLs using both ASP.NET MVC and now ASP.NET Web Forms (you can also have applications that mix the two).

https://weblogs.asp.net/scottgu/url-routing-with-asp-net-4-w...

> you can't run webforms + MVC Core side-by-side

Besides the obvious IFRAME approach, one could have a single solution with both a ASP.NET Web Application project and another MVC (or Blazor) project. Both of them would reference shared models/services via some .NET Standard 2.0 project. IIS can host ASP.NET Core.

Then start refactoring and rewrite the old HTML4/CSS2 into HTML5/CSS4, while the Server Controls and Master Pages become Razor Components.

There is definitely an upgrade path.

That generally requires a reverse proxy or content-switch. That reverse proxy will then have to lie to one or both apps about their URLs, etc...

Microsoft is recommending YARP for this: https://learn.microsoft.com/en-us/events/dotnetconf-2022/mig...

That sounds okay, but you'll hit all sorts of fun technical challenges. Good look making WCF client certificate authentication work through this! There are also performance gotchas with buffering, etc...

There are not-atypical scenarios where during a migration, an app might be behind 4+ reverse proxies, all of which are different products.

E.g.: CDN -> App Gateway WAF v2 -> Kubernetes Ingress -> YARP -> Legacy App.

You'll quickly discover all sorts of fun interactions between these and 15-year-old ASP.NET code!

The end result is that .NET Framework is the Python 2 of the .NET world, and a major slice of anything .NET that I happen to touch on for enterprise consulting.