EDIT: more on this here https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0...
EDIT: more on this here https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0...
> There will be just one .NET going forward
> Additionally, we wanted to clearly communicate that .NET 5 is the future for the .NET platform.
If "one isn't going to be developed anymore" there there will be just one framework.
"Being" here means what's the official worked-on implementation. Not merely existing, obviously the code for 4.8 wont go anywhere, nor will existing deployments suddenly vanish.
I took "forever" to mean that they would still be issuing security patches to 4.8, for example. Given all that I don't know why you're insisting on phrasing it like that. There is only one future, sure. But you seem to be making it sound like 4.8 has a planned obsolescence date or something and Microsoft is saying the exact opposite.
Maybe a better analogy is that .NET Framework 1.x and .NET Framework 2-4.x are side-by-side installed still in Windows 10. If you wanted you could still target .NET 1.0 and it will run in an entirely different runtime (.NET 1.x and 2.x are hugely different). .NET was designed for that sort of side-by-side deployment, they just haven't done it in a while.
Yet I've not met a developer that still sees .NET 1.x as a viable Framework recently. Do you want .NET 4.8 applications to just break? What do you expect here? The "current framework" is always a combination of marketing and support and this article seems pretty clear that all marketing and support effort will be on .NET 5, and .NET 4.8 is "done".
That's not true at all. You can run any version of the framework side-by-side all the way back.
You can have .NET 2 or whatever older on the same machine too.
Doesn't change the fact that .NET 5 will be the single official .NET release onwards, where development efforts will be concentrated, etc. It's not like MS will support 2 different frameworks (except one as a legacy release).
Yes, some of those items are legacy, but not everyone enjoys paying to rewrite stuff from scratch.
I suppose their rationale is damage control ("Okay, they get the server, but the desktop is still firmly ours"), but it would certainly keep me from starting a personal project with a Microsoft Framework.
At this point I'm guessing that it's because there isn't a strong future for desktop apps written in native code. Even VSCode is written on top of Electron. Good, bad, or indifferent I think that there isn't a lot of point in developing a native GUI framework at this point.
(To be clear - I'm 100% sure that there are a lot of use cases that I'm blithely waving away, but I'm also sure that those use cases are currently being addressed with WinForms, Qt, GNOME, etc, etc, so why should MS invest in Yet Another GUI Framework?)
I also tend to agree that for good, or bad, that Electron will probably grow significantly as an application base. Like I see node becoming the defacto runtime for WebAssembly, I see Electron taking that place for WebAssembly + UI. And I don't think it's all that bad.
Even with MS, Electron seems to be their unified UI target for a lot of apps. VS Code, Teams, Azure SQL Studio (or whatever the name is now), and don't see that space shrinking. I'm only surprised that Teams doesn't have an official Linux version.
So it would make sense if they're pushing .Net Core to be cross-platform, that they want to eventually push the Microsoft App Store "buy" button to be cross-platform as well, with a GUI framework to support those apps. Speculation, but .. of course they will want to.
I don't want to be the one stating on RFP "it kind of works".
"Both .NET Framework and .NET Core will move forward, and both will be fully supported"
???
Which is why I found this one confusing... because it essentially says the opposite.
"We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes."