Almost THREE years after picking up ASP.NET Core, 1.1 at the time, things are finally shaping up and ASP.NET Core is ready for prime time. I'm about to convert the last website to use ASP.NET Core.
I managed to keep YetaWF source code shared between ASP.NET 4 and ASP.NET Core with the same feature set, but it's time to cut the cord and switch to ASP.NET Core completely. The performance using ASP.NET Core 3.0 is simply a lot better. And runs on Linux and Docker too.
Having converted a number of sites, split off micro-services running in Docker, it was well worth the investment, both time and money. It certainly didn't come cheap, but the end result is worth it.
I have been a harsh critic of ASP.NET Core (still am), and some decisions made by the ASP.NET Core team were just plain wrong (or bad), but the overall end result is useable and works.
Even in this latest iteration of ASP.NET Core (3.0), some trivial items are causing WAAAYYYYY more pain than should be expected in a framework upgrade. The new reality that a new, major release will always break things is just wrong. Why would anyone willingly accept this as a fact? It's only a fact because you believe this should be tolerated. I have code dating back to the 90's written in C/C++ using the Windows API (see https://softelvdm.com) that STILL works. Nothing broke in decades. Yes, it was updated to support features in new Windows versions, but nothing ever broke, or stopped compiling.
First of all, why would things need to be changed so fundamentally in a framework like ASP.NET Core, that's barely 3 years old? Usually the answer is that the initial implementation was flawed. So changes had to be made. Or maybe the (breaking) changes provided sooo much more benefit than pain?
Let's take a look at the new features in 3.0 that caused me some pain. Endpoints. No more synchronous http responses. "Async" is removed from controller actions. There are compatibility switches for these items. Their defaults may have been poorly chosen, which make them all breaking changes. At least they're fixable. I just wish they didn't require 100% code coverage testing and even edge case testing. Particularly "No more synchronous http responses" requires way more testing because you won't find all problems in a development environment. So I decided to enable "sync" on a case by case basis (in development), but always enable it in production. I'd rather not crash in production.
The front-end devs will get bitten by the "no more Async in controller actions" for sure. Fortunately I never used the Async suffix in actions, even though VS 2017 always tried to "auto correct" that and included Async in actions when an action was made async. Well I did use it once by accident, in a POST action, which I didn't find in automated testing.
Overall, 3.0 is a solid release, with just a few not ideal defaults, but nicely done.