> And now we have .NET 5 which is neither Framework nor Core
Just to note, the blog post explicitly says that .NET 5 is the next version of .NET Core. It's where .NET Core is going, and given that so much more of the .NET "picture" is being realized with it, the name is changing to be more reflective of the fact that it's not really a "core" (small) thing anymore.
Yes, indeed. But will that change also apply to the other projects that target .NET Core (now ".NET")? Will Entity Framework Core become Entity Framework and clash with the 'full-fat' Entity Framework? The blog post suggests this won't happen by referencing ASP.NET Core 3.
And where does this leave the legacy .NET Framework? It reads as a sub-project of '.NET' (previously .NET Core) but it very much isn't because it provides a set of older APIs. We seemingly have two meanings for .NET now, referring to .NET Core (which I guess only applies when suffixed with v5+) and the wider array of .NET projects, whatever they are.
I missed that, and that would be a pretty big deal. I thought the message was of a side by side evolution, with full framework getting features possibly with a delay.
Well, it is not really the case, there will be still two frameworks, just one isn't going to be developped anymore (full .net 4.8). The way I read that sentence initially was them merging the two into one.
>Well, it is not really the case, there will be still two frameworks, just one isn't going to be developped anymore (full .net 4.8).
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.
What they are saying at MS Build is 4.8 will be supported "forever" because there is too much code depending on .NET Framework, but new feature development is going into .NET Core 3+. By the time they reach .NET 5, they will have unified .NET Core, .NET Standard and Xamarin. They are skipping version "4" to avoid confusion with the second .NET Framework 4.8.
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.
When 4.8 is installed, 4.7 is going away. Here .net 5 will not replace .net 4.8, it will exist side by side (if I understand correctly). That's two frameworks to me.
The VB6 runtime is still installed on Windows 10, but no one (should) considers that a viable Framework to target in 2019.
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".
Yes, major versions install side-by-side (except v2-v3) because they aren't perfectly backward compatible and this is necessary for legacy app support. So, you can need all of .NET Framework 1.1, 3.5, and 4.8 now, and in the future .NET 5.x is added to the list.
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).
All the desktop stuff is only on Windows though, right? If I'm not mistaken this is the first major .NET Core component that is not cross-platform, which is confusing in itself.
They explicitly won't support cross-platform efforts for the GUI stuff, as stated on GitHub (though maybe, one day ...).
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 wouldn't mind seeing WPF, or a descendent, ported to other platforms. Xamarin Forms, Eto Forms, and a lot of other wrappers already do a lot of that though, if you want cross platform gui from .Net. (god that looks sloppy)
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.
WinForms is outdated, "replaced" by WPF and I think apps on the Microsoft App Store have to use WPF instead of WinForms.
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.
You can't publish WinForms or WPF applications to the Microsoft Store, they've both been replaced. It's only UWP or using MS's tooling to convert Electron apps to UWP.
Yep, I've semplified. What I understood from this post is that net framework is in "maintenance mode": probably MS plan a 4.8.1 with but fixes and maybe a 4.9 with some minor updates, but .net core (now simply .net) is the place where new things will be developed.
Nothing in the article suggests maintenance releases, but MS' history is probably enough for that. The article does definitely state that .Net 5 is the evolution of Core and will be the entire platform going forward. I'm, personally, glad to see Core/Framework/Mono etc rolled into a single version at 5. The previous split versions have been fairly confusing.
Fair enough - but the wealth of documentation for it will continue to exist, as will older applications targetting it. This seems problematic if you want to search for ".NET" (meaning .NET Core).
The post is a vision-setting announcement about where .NET is headed. The finer details like you've described will be worked out in the following 1.5 years.
If you're developing an application with a Windows desktop GUI, you're still doing it on full framework (WPF, WinForms, UWP). They're folding that into .NET 5, and I haven't seen anything indicating that they see that as "doing it wrong". This is only one case of developing for full framework, but it's a big one. I imagine any other cases where the developer community really needs full framework capabilities that still aren't ported to CoreCLR, they'll fold that in just the same as with the UI frameworks, as a Windows-specific capability. Maybe they end up sunsetting more than I think, but for now this seems more like consolidating Core and Framework than ending Framework.
Last time I tried to seriously switch from Framework to Core, I was dismayed to find that Assemblies could not be unloaded from memory in Core after they were loaded. That was something that depended on the AppDomain functionality, which existed in Framework only.
There are a ridiculous amount of first-party Microsoft SDKs for products they are pushing heavily that don't support Core yet.
Unless there is a newer version than last month, one of those is the Bot Framework extensions for Microsoft Teams, which they are just slamming ahead with.
Just to note, the blog post explicitly says that .NET 5 is the next version of .NET Core. It's where .NET Core is going, and given that so much more of the .NET "picture" is being realized with it, the name is changing to be more reflective of the fact that it's not really a "core" (small) thing anymore.