7 ms·

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

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

lol768 7y ago
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.
- D_Guidi 7y ago
  Legacy net framework Will stop with 4.8, as said some months ago EDIT: more on this here https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0-and-net-framework-4-8/ https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0...
  - lol768 7y ago
    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).
  - cm2187 7y ago
    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.
    - manigandham 7y ago
      There's no point since .NET Core 3.0 can run desktop applications now.
      - lol768 7y ago
        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.
        manigandham 7y ago
        Yes, since it's using Windows components like WPF. I dont think they ever had a plan for a cross-platform desktop UI kit.
        solarkraft 7y ago
        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.
        MikeTheGreat 7y ago
        > but the desktop is still firmly ours 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?)
        7y ago
  - james_s_tayler 7y ago
    But that article says: "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.
    - D_Guidi 7y ago
      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.
      - brianberns 7y ago
        I don’t see anything in the linked article that supports your conclusion.
        tracker1 7y ago
        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.
        D_Guidi 7y ago
        yep! this blog post is more clear about future releases: https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ https://devblogs.microsoft.com/dotnet/net-core-is-the-future... "We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes."
      - runfaster2000 7y ago
        Here is the post you are looking for, I think ... https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ https://devblogs.microsoft.com/dotnet/net-core-is-the-future...
- phillipcarter 7y ago
  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.
pknopf 7y ago
I look at this ".NET 5" thing as a PR move to end full framework. "We aren't ending full framework, we have .NET 5!" If you are developing new apps in full framework, you are doing it wrong.
- pjmlp 7y ago
  Then we are doing it wrong, until the 3rd party libraries that we require, actually bother to make it right.
- tstrass 7y ago
  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.
- thrower123 7y ago
  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.
- Nuzzerino 7y ago
  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. Thankfully, they finally got around to adding support in .NET 3.0 (https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/ https://www.strathweb.com/2019/01/collectible-assemblies-in-...).

lol768 7y ago

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.

D_Guidi 7y ago
Legacy net framework Will stop with 4.8, as said some months ago EDIT: more on this here https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0-and-net-framework-4-8/ https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0...
- lol768 7y ago
  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).
- cm2187 7y ago
  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.
  - manigandham 7y ago
    There's no point since .NET Core 3.0 can run desktop applications now.
    - lol768 7y ago
      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.
      - manigandham 7y ago
        Yes, since it's using Windows components like WPF. I dont think they ever had a plan for a cross-platform desktop UI kit.
        solarkraft 7y ago
        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.
        MikeTheGreat 7y ago
        > but the desktop is still firmly ours 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?)
        7y ago
- james_s_tayler 7y ago
  But that article says: "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.
  - D_Guidi 7y ago
    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.
    - brianberns 7y ago
      I don’t see anything in the linked article that supports your conclusion.
      - tracker1 7y ago
        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.
      - D_Guidi 7y ago
        yep! this blog post is more clear about future releases: https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ https://devblogs.microsoft.com/dotnet/net-core-is-the-future... "We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes."
    - runfaster2000 7y ago
      Here is the post you are looking for, I think ... https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ https://devblogs.microsoft.com/dotnet/net-core-is-the-future...
phillipcarter 7y ago
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.

pknopf 7y ago

I look at this ".NET 5" thing as a PR move to end full framework. "We aren't ending full framework, we have .NET 5!" If you are developing new apps in full framework, you are doing it wrong.

pjmlp 7y ago
Then we are doing it wrong, until the 3rd party libraries that we require, actually bother to make it right.
tstrass 7y ago
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.
thrower123 7y ago
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.
Nuzzerino 7y ago
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. Thankfully, they finally got around to adding support in .NET 3.0 (https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/ https://www.strathweb.com/2019/01/collectible-assemblies-in-...).