7 ms·

.NET Core, .NET 5; the Exodus of .NET Framework?

57 points by ozdave 7y ago

stefan_ 7y ago
The author seems to make a rather classic mistake; once told, I'm sure you'll recognize it in some of your current and past coworkers: they become intimately involved and emotionally invested in the evolution of their chosen toolkit. In C++, which has a large community with this particular affliction, this usually means their code stops compiling with anything but a HEAD clang targeting C++20 and becomes utterly unrecognizable. In C#, following this post, a few framework gimmicks will apparently not be implemented in the old .NET: all code must utilize them or risk "exodus". Java had a good immunization protocol: don't change the language for 10 years. All those people moved to Scala. Meanwhile, of course, the real world continues to run just fine with ancient software written in ancient languages compiled with ancient tooling, targeting ancient operating systems. Your router is on Linux 2.6. Hell, you can start a new application targeting .NET Framework 4 today and Microsoft will keep that stuff running for another 20 years on Windows.
- deleted 7y ago
  [deleted]
- lern_too_spel 7y ago
  No, the problem is that their dependencies will use the new gimmicks, and if they need feature or security updates in those dependencies, they will need to migrate their applications to the new platform.
  - tonyedgecombe 7y ago
    This is the problem with open source dependencies, they often don't have the financial pressures nor resources to maintain what the users need.
    - Nuzzerino 7y ago
      Not sure why the downvotes, as this has been my experience numerous times, particularly in the Node.JS world.
drummer 7y ago
Microsoft are going to support .net 4.8 untill the end of time. Nothing to worry about. Only if you want new stuff that will only come in 5.0 will you require the migration.
- Nitramevfank 7y ago
  That's not really how it works in practice in my experience. In some time, some thing you use needs to be patched and the latest version only runs on the newer platform. Doesn't matter if the underlying platform is supported if the entire ecosystem moved elsewhere.
  - daveoc64 7y ago
    The most recent versions of the .NET Framework (including 4.8, the final version) are supported for as long as the OS they are installed on is supported. I think that because of that longevity, you're going to see lots of the main libraries etc. supporting .NET Framework for years to come.
    - 9wzYQbTYsAIc 7y ago
      Developing to the right .NET Standard spec will ensure compatibility between ‘old’ .NET Core and the legacy .NET Framework 4.8. Libraries that do so would be limited in their ability to use new language and framework features though.
- jen20 7y ago
  This rather misses the point of the article. The article states that ALTHOUGH Microsoft will continue to support .NET Framework 4.8 effectively forever, OSS authors will not.
hbcondo714 7y ago
There was a healthy discussion here on HN 8 months ago about .NET 4.X when MS announced .NET 5: https://news.ycombinator.com/item?id=19840763 https://news.ycombinator.com/item?id=19840763
caseymarquis 7y ago
I've been using .NET Core for new projects since it first came out, and I think it's important to remember that a couple years back .NET Core wasn't really stable enough for production use (in comparison to .NET Framework). The original project files were in a different format, you often had to fight the tooling, and important libraries like Entity Framework were missing key features. Despite that, the fact that Linux was a target platform made the whole thing worth it. Core 2.0 came out mid 2017, and in my mind I still wasn't sure .NET Core had cooled down enough to port applications from .NET Framework. 2.0 turned out to largely be stable enough for production, but there wasn't really any way of knowing that without watching it for a few years. We've only just gotten to the point where moving an important production code base to .NET core actually feels like the correct thing to do. I'm sure there will still be some hurdles involved, but at least there won't be too many landmines.
- qes 7y ago
  > have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. That's not true. Friction in tooling and project description files does not really equate to instability for production use - "worth it" is quite subjective and also not equatable to stable. As you said, Core v2 was already out 2 years ago, and plenty of people were using Core v1.X in production on significant sites without much trouble.
tasogare 7y ago
Dotnet Core is nice for server software, but Microsoft still didn't address the biggest pain point for desktop applications: the lack of a multi-platform UI framework. This is a pure "strategic" decision, as Silverlight was released for OSX as well as Windows. Instead, they persisted on their UWP platform which didn't even run of the most deployed version of Windows (Win 7) and that unsurprisingly nobody wants to use. Pure sabotage, which is sad because the development tools are great (Visual Studio is my favorite IDE by far).
- skc 7y ago
  I work in corporate and desktop applications are very clearly being phased out in favor of the web. I see this trend accelerating so for once it seems Microsoft has read the tea leaves correctly.
  - tasogare 7y ago
    I know. But in my opinion it's not just that they read the leaves, it's also they push their own platform towards irrelevance and thus the whole situation is a kind of self-fulfilling prophecy. In comparison to say WPF, the web stack was very lacking. It wasn't for example until a few years ago that we got CSS grids. Heck, HTML components are still not mainstream, despite solving a very problem... which doesn't elsewhere.
- undebuggable 7y ago
  > Microsoft still didn't address the biggest pain point for desktop applications: the lack of a multi-platform UI framework With the current state of the tech it would be Qt (very awkward for the web though, using WASM?), or a modern web framwework with a design framework (e.g. Angular + Material Design) inside native wrappers. I don't see how MS could step in with some silver bullet solution.
- Nelkins 7y ago
  Is this really the biggest pain point? I'm not sure this is a dire need for most businesses. WPF has a compatibility layer that allows developers to use it with .NET Core on Windows. Xamarin.macOS exists if you want the native look for macOS. There's already GTK bindings if you need something cross-platform, and a variety of other OSS projects (Avalonia and Eto come to mind, but I know there are others). I'm just not sure x-plat desktop is a place where MS needed to step in to fill the void.
fowl2 7y ago
This schism cuts from both sides: have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. Many of Microsoft's own libraries such as Sharepoint and Dynamics don't support Core and many don't even have clear signalled intention to do so. Classic "big bang flag day, break compatibility" problems.
- rk06 7y ago
  >have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. Can you give any examples? Generally, .NET Standard aims to fix the problem. If you upgrade to .NET 4.8(or atleast .NET 4.7.2), you can use libraries targetting .NET Standard v2.0(and below) So, new libraries can support both NET Framework. (Unless the authors don't want to Or can't) It is not a perfect solution as library maintainers need to put effort into migrating to NET Standard. But if library authors have not done it by now, then perhaps you should use a different library
  - to11mtm 7y ago
    > It is not a perfect solution as library maintainers need to put effort into migrating to NET Standard. But if library authors have not done it by now, then perhaps you should use a different library The effort isn't very difficult in my experience; switch CSPROJ formats, edit the file to be multi-framework, rinse repeat. Your build scripts and/or CI pipeline will probably be where more of the work is. That said... >>have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. >Can you give any examples? WCF.
  - fowl2 7y ago
    > Can you give any examples? Sharepoint, Dynamics... ;) > So, new libraries can support both NET Framework. (Unless the authors don't want to Or can't) It's possible, yes. The more "active", smaller, newer libraries are already starting to get sick of this and remove support for Framework. ASP.NET for example. Further compounding the situation is when libraries take it as an opportunity to make compatibility breaks themselves. Some MS examples include Powershell, ASP.NET and Entity Framework.

57 points by ozdave 7y ago

The author seems to make a rather classic mistake; once told, I'm sure you'll recognize it in some of your current and past coworkers: they become intimately involved and emotionally invested in the evolution of their chosen toolkit. In C++, which has a large community with this particular affliction, this usually means their code stops compiling with anything but a HEAD clang targeting C++20 and becomes utterly unrecognizable. In C#, following this post, a few framework gimmicks will apparently not be implemented in the old .NET: all code must utilize them or risk "exodus". Java had a good immunization protocol: don't change the language for 10 years. All those people moved to Scala. Meanwhile, of course, the real world continues to run just fine with ancient software written in ancient languages compiled with ancient tooling, targeting ancient operating systems. Your router is on Linux 2.6. Hell, you can start a new application targeting .NET Framework 4 today and Microsoft will keep that stuff running for another 20 years on Windows.

deleted 7y ago
[deleted]
lern_too_spel 7y ago
No, the problem is that their dependencies will use the new gimmicks, and if they need feature or security updates in those dependencies, they will need to migrate their applications to the new platform.
- tonyedgecombe 7y ago
  This is the problem with open source dependencies, they often don't have the financial pressures nor resources to maintain what the users need.
  - Nuzzerino 7y ago
    Not sure why the downvotes, as this has been my experience numerous times, particularly in the Node.JS world.

drummer 7y ago

Microsoft are going to support .net 4.8 untill the end of time. Nothing to worry about. Only if you want new stuff that will only come in 5.0 will you require the migration.

Nitramevfank 7y ago
That's not really how it works in practice in my experience. In some time, some thing you use needs to be patched and the latest version only runs on the newer platform. Doesn't matter if the underlying platform is supported if the entire ecosystem moved elsewhere.
- daveoc64 7y ago
  The most recent versions of the .NET Framework (including 4.8, the final version) are supported for as long as the OS they are installed on is supported. I think that because of that longevity, you're going to see lots of the main libraries etc. supporting .NET Framework for years to come.
  - 9wzYQbTYsAIc 7y ago
    Developing to the right .NET Standard spec will ensure compatibility between ‘old’ .NET Core and the legacy .NET Framework 4.8. Libraries that do so would be limited in their ability to use new language and framework features though.
jen20 7y ago
This rather misses the point of the article. The article states that ALTHOUGH Microsoft will continue to support .NET Framework 4.8 effectively forever, OSS authors will not.

hbcondo714 7y ago

There was a healthy discussion here on HN 8 months ago about .NET 4.X when MS announced .NET 5: https://news.ycombinator.com/item?id=19840763 https://news.ycombinator.com/item?id=19840763

caseymarquis 7y ago

I've been using .NET Core for new projects since it first came out, and I think it's important to remember that a couple years back .NET Core wasn't really stable enough for production use (in comparison to .NET Framework). The original project files were in a different format, you often had to fight the tooling, and important libraries like Entity Framework were missing key features. Despite that, the fact that Linux was a target platform made the whole thing worth it. Core 2.0 came out mid 2017, and in my mind I still wasn't sure .NET Core had cooled down enough to port applications from .NET Framework. 2.0 turned out to largely be stable enough for production, but there wasn't really any way of knowing that without watching it for a few years. We've only just gotten to the point where moving an important production code base to .NET core actually feels like the correct thing to do. I'm sure there will still be some hurdles involved, but at least there won't be too many landmines.

qes 7y ago
> have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. That's not true. Friction in tooling and project description files does not really equate to instability for production use - "worth it" is quite subjective and also not equatable to stable. As you said, Core v2 was already out 2 years ago, and plenty of people were using Core v1.X in production on significant sites without much trouble.

tasogare 7y ago

Dotnet Core is nice for server software, but Microsoft still didn't address the biggest pain point for desktop applications: the lack of a multi-platform UI framework. This is a pure "strategic" decision, as Silverlight was released for OSX as well as Windows. Instead, they persisted on their UWP platform which didn't even run of the most deployed version of Windows (Win 7) and that unsurprisingly nobody wants to use. Pure sabotage, which is sad because the development tools are great (Visual Studio is my favorite IDE by far).

skc 7y ago
I work in corporate and desktop applications are very clearly being phased out in favor of the web. I see this trend accelerating so for once it seems Microsoft has read the tea leaves correctly.
- tasogare 7y ago
  I know. But in my opinion it's not just that they read the leaves, it's also they push their own platform towards irrelevance and thus the whole situation is a kind of self-fulfilling prophecy. In comparison to say WPF, the web stack was very lacking. It wasn't for example until a few years ago that we got CSS grids. Heck, HTML components are still not mainstream, despite solving a very problem... which doesn't elsewhere.
undebuggable 7y ago
> Microsoft still didn't address the biggest pain point for desktop applications: the lack of a multi-platform UI framework With the current state of the tech it would be Qt (very awkward for the web though, using WASM?), or a modern web framwework with a design framework (e.g. Angular + Material Design) inside native wrappers. I don't see how MS could step in with some silver bullet solution.
Nelkins 7y ago
Is this really the biggest pain point? I'm not sure this is a dire need for most businesses. WPF has a compatibility layer that allows developers to use it with .NET Core on Windows. Xamarin.macOS exists if you want the native look for macOS. There's already GTK bindings if you need something cross-platform, and a variety of other OSS projects (Avalonia and Eto come to mind, but I know there are others). I'm just not sure x-plat desktop is a place where MS needed to step in to fill the void.

fowl2 7y ago

This schism cuts from both sides: have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. Many of Microsoft's own libraries such as Sharepoint and Dynamics don't support Core and many don't even have clear signalled intention to do so. Classic "big bang flag day, break compatibility" problems.

rk06 7y ago
>have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. Can you give any examples? Generally, .NET Standard aims to fix the problem. If you upgrade to .NET 4.8(or atleast .NET 4.7.2), you can use libraries targetting .NET Standard v2.0(and below) So, new libraries can support both NET Framework. (Unless the authors don't want to Or can't) It is not a perfect solution as library maintainers need to put effort into migrating to NET Standard. But if library authors have not done it by now, then perhaps you should use a different library
- to11mtm 7y ago
  > It is not a perfect solution as library maintainers need to put effort into migrating to NET Standard. But if library authors have not done it by now, then perhaps you should use a different library The effort isn't very difficult in my experience; switch CSPROJ formats, edit the file to be multi-framework, rinse repeat. Your build scripts and/or CI pipeline will probably be where more of the work is. That said... >>have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new. >Can you give any examples? WCF.
- fowl2 7y ago
  > Can you give any examples? Sharepoint, Dynamics... ;) > So, new libraries can support both NET Framework. (Unless the authors don't want to Or can't) It's possible, yes. The more "active", smaller, newer libraries are already starting to get sick of this and remove support for Framework. ASP.NET for example. Further compounding the situation is when libraries take it as an opportunity to make compatibility breaks themselves. Some MS examples include Powershell, ASP.NET and Entity Framework.