christianAtSuddath
commented
2 weeks ago Well said @richstokoe ! Thank you for taking the time to verbalize what I have been thinking.
I found this issue after spending days and a good amount of my employer's money trying to convert a .Net Core 6.0 SPA with Angular 15 to a .Net Core 8.0 (LTS) SPA with Angular 18. It already took several days to get the code to compile, serve locally, debug and test successfully. Since yesterday I'm stuck with the next issue: Our Azure web app is not longer serving up index.html, even after modifying the ...server.csproj with removing the extra "wwwroot/browser" paths and having the client-side files right under the wwwroot, where the web.config sits. What an expensive frustration! It's not that I'm trying this for the first time. We've been using the .NET Core / Angular templates since .NET Core 3.1. Again, thank you @richstokoe !
Also, thank you to @javiercn who has updated https://github.com/dotnet/AspNetCore.Docs/issues/26373.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Developers who already have significant JavaScript-based SPA applications (built through encouragement by Microsoft) have been abandoned by the ASP.NET team. Blazor is the new hotness (for good reasons) however, those of us unable or unwilling to stop all revenue-driving development in favour of a large migration to Blazor that delivers no customer nor business value are left out in the cold.
Most frustratingly, Microsoft has been evasive and not taken clear opportunities to share the intention to drop JS-based SPA developers sooner, leaving us without an LTS version of the framework to use.
I wrote at length about the unnecessary change from SpaServices to SpaProxy in .NET 6 here: https://richstokoe.com/2022/02/07/deconstructing-the-new-inner-loop-for-single-page-applications-spas-in-net-6/ this was even before the ASP.NET team started discussing the need for documenting this: https://github.com/dotnet/AspNetCore.Docs/issues/26373 with others also asking for the same thing 3 months before the documentation was written (https://github.com/dotnet/aspnetcore/issues/42732)
For those of us building modular monoliths, with both front end and back end in the same project, we are being forced to split these into separate applications, incurring new transient failure modes we explicitly set out to avoid. (Note: Even Blazor templates encourage mixing front end and back end code in a single service!)
I highlighted that changes since .NET 6 have forced developers to re-architect their applications to suit this new development-time behaviour. Most worryingly, I highlighted that this change meant that by design code now ran differently in production compared to in development - I was bitten by this in production whereby in development I was routed to a JavaScript SPA for a particular URL and in production I was routed to an MVC view. This is not OK. This is very dangerous and there are real livelihoods at stake. The cost to test has increased and the confidence to release has plummeted.
The migration steps (documented 45 days before EOL of .NET 5) are non-trivial: https://github.com/dotnet/aspnetcore/issues/44600
This change has also caused myriad other changes to be made and it feels like the .NET team are either accidentally (law of unintended consequences and second order effects) or deliberately (to drive customers to Blazor) ruining the JS-based SPA development experience. For example, having to introduce ASPNETCORE_HOSTINGSTARTUPASSEMBLIES, to inject code into the process just to get SpaProxy to work. Having to clean up the complete mess that was log4shell a couple of years ago I'm shocked that anyone is making external code injection easier these days...
This rearchitecture has broken a lot of customers with very common use cases. Myself and a few other users have hit roadblocks trying to speak to the team with some discussions just going cold and being automatically closed.
mkArtakMSFT has finally conceded that SpaProxy is not part of the longer term framework roadmap (https://github.com/dotnet/aspnetcore/issues/49605) and that anything not Blazor is now a Community problem.
And now, with .NET 8, the SPA templates have been dropped from the default install and we need to use community templates. (https://github.com/dotnet/aspnetcore/issues/49388) This is pretty sickening.
For those of us who have been early adopters, drove adoption in our teams and organisations, built large applications on your recommendations, put up with documentation not being updated til the last second, and tried to keep up to date, the experience since .NET 6 is that we don't matter anymore and only those starting new projects where Blazor can be used from scratch are the customers you care about and wish to support.
Describe the solution you'd like
My request is simple. Please re-engage with us existing customers who have ploughed millions of dollars into Visual Studio, Azure and .NET to build and host apps the way you told us to.
We aren't all in a position to start projects from scratch with Blazor and train people up on it. Continuing support for previously-recommended ways of working should be table stakes, even across versions of the frameworks.
At the very least, give us more than 45 days notice that we need to completely rearchitect our applications to remain on LTS versions of the framework (especially when the communitu has been asking for documentation for months prior).
Additional context
I hope there is enough detail and examples of customers having similar issues, clearly showing the problems the community are now having raising concerns with the .NET teams and the self-inflicted additional work the teams have incurred, to prompt a review of the .NET team's relationship with the JS-based client side development community.
Trust does not come easily and the dismissive attitude by .NET team members has burned a lot of trust. React and Angular are still the preferred client side development framework for many and while Microsoft may want to dominate this space with Blazor, this shows that lessons of the past have not been learned. You have to work with us, not try to force our hands. We're willing to work with you (hence going to the repeated effort to engage with you) but you need to show willing to work with us too. We rant because we still care, once we go silent, that's when it's too late as we've gone elsewhere.
Aspire is the next new shiny thing, so I doubt this will even get noticed, but that would be doing us customers spending a fortune with you a serious disservice.
CC: @coolcsh