4 ms·

The writing was on the wall a long, long time ago! These companies had 15 years to do it. And it was fairly easy to get webforms + MVC running side-by-side on

The writing was on the wall a long, long time ago! These companies had 15 years to do it. And it was fairly easy to get webforms + MVC running side-by-side on the same site so you could gradually migrate. Too late for that now though, you can't run webforms + MVC Core side-by-side. You could put a load balancer in front of the old app and start moving end points to a new code base. It's akin to moaning that MS haven't got an upgrade path from IE7. Or your Adobe Air app has stopped working. On the plus side, doesn't 4.7 still have a huge support window because it's tied to one of the windows server versions?

alexjplant 4y ago
> 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.
- andix 4y ago
  Classic management f**-up. Some products/companies just die, because of bad management that doesn’t react to change. Get a new job ;)
  - alexjplant 4y ago
    > 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.
    - andix 4y ago
      Sure, but at some point the last sane developer either quits or retires, and then they are completely f*ed.
      - mcbits 4y ago
        15 years of management experience. Oversaw the reduction of personnel expenditures by 90%. They'll do fine.
- WorldMaker 4y ago
  > 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.
jiggawatts 4y ago
> 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
- mattmanser 4y ago
  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-web-forms-vs-2010-and-net-4-0-series https://weblogs.asp.net/scottgu/url-routing-with-asp-net-4-w...
mycall 4y ago
> 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.
- jiggawatts 4y ago
  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/migrate-your-legacy-aspnet-projects-to-aspnet-core-incrementally-with-yarp 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!
pjmlp 4y ago
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.

alexjplant 4y ago

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

andix 4y ago
Classic management f**-up. Some products/companies just die, because of bad management that doesn’t react to change. Get a new job ;)
- alexjplant 4y ago
  > 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.
  - andix 4y ago
    Sure, but at some point the last sane developer either quits or retires, and then they are completely f*ed.
    - mcbits 4y ago
      15 years of management experience. Oversaw the reduction of personnel expenditures by 90%. They'll do fine.
WorldMaker 4y ago
> 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.

jiggawatts 4y ago

> 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

mattmanser 4y ago
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-web-forms-vs-2010-and-net-4-0-series https://weblogs.asp.net/scottgu/url-routing-with-asp-net-4-w...

mycall 4y ago

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

jiggawatts 4y ago
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/migrate-your-legacy-aspnet-projects-to-aspnet-core-incrementally-with-yarp 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!

pjmlp 4y ago

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.