4 ms·

> The compatibility break with the .NET Framework also removed the biggest advantage I saw in C# I'll be honest here. The migration from .NET Framework to .NET

> The compatibility break with the .NET Framework also removed the biggest advantage I saw in C# I'll be honest here. The migration from .NET Framework to .NET Core is a pain. I see why things were done the way they were done, but it's still a real pain. That said: for green-field works NET Core is clearly superior. > PowerShell Core is past version 7 but is still missing many modules, including some key Microsoft ones Just like .NET Core's main mission was not to replace the entire .NET Framework, the same applies to PowerShell Core. .NET Core was created to make developing .NET-based web/cloud-services easier, faster, using less space/resources at runtime, and to have a fully supported cross-platform story. And at that it has been a wild success. Almost everything about .NET Core is better to work with than the traditional .NET Framework (at least for the workloads it was intended for), and I'm always depressed when I have to move back to work on the "old" stack. In this regard PowerShell Core is (as I see it) not meant to fully replace regular PowerShell either, but to be a good platform to do your cross-platform dev-ops'y build and deployment scripts related to your .NET Core deliverables. It may not be what you want it to be, but it has a clear mission, and it's delivering fairly well on that. > Lastly, I got fed up with Microsoft releasing yet another half-baked GUI framework. I think this applies to pretty much everyone, which is why they never catch on, and Microsoft inevitably trying to "solve" this by releasing yet another framework. That said the MAUI-presentation on this year's Build looked pretty convincing. If I had time to spare and had some small projects/POCs I had to work on, I might had given it a spin.

ptx 6y ago
But if .NET Core was not meant to replace the .NET Framework, why is Microsoft doing just that with .NET 5? (Yes, the old framework will still exist after it's been replaced - the same way VB 6 still exists after being replaced by VB.NET and IE still exists after being replaced by Edge.)
- josteink 6y ago
  You are allowed to change your mind, aren't you? :) The goal for the initial .NET Core project was to have something cross-platform, modular and lightweight to build Linux-deployable cloud-services with. Once that reached a mature state, they could expand scope. And now, after .NET Core 3.x has landed, it has matured so much, that MS can see one single unified path forward which also includes some things which previously was only possible using the traditional .NET Framework (4.8). So now they are adding those use-cases to the "Core" package as well, without compromising on what .NET Core was supposed to deliver. I honestly don't see anything wrong with that.
  - ptx 6y ago
    Right, but I think the complaint was that it was still immature and missing some use-cases covered by the old framework. Anyway, I do hope they succeed and the .NET 5 unification goes smoothly. I want those C# 9 features - but I also need some old third-party libraries to keep working.
    - ta17711771 6y ago
      Which ones, if you don't mind me asking out of curiosity?
      - ptx 6y ago
        Which features? Mostly data classes, a.k.a. records, and (from C# 8) non-nullable references. Kotlin has had these features for years and it makes things so much easier and cleaner IMHO.
        jasonlhy 6y ago
        I believe they tried to keep the C# version independently from the framework version, so people can use the new C# version on a old .net framework. But things seem impossible for some new features, for example async steam just need new feature from core CLR. So after .C#8, they decide only to support it on .NET core
  - goto11 6y ago
    The problem is it leaves all .net framework code on a dead-end platform. For all previous .net versions, code could be easily and safely upgraded to the next version because they were largely backwards compatible. But you can't easily upgrade existing code from 4.8 to 5. If you want to start a project from scratch, sure Core/5 is nice.
    - josteink 6y ago
      > For all previous .net versions, code could be easily and safely upgraded to the next version because they were largely backwards compatible. But you can't easily upgrade existing code from 4.8 to 5. As someone who has been working with .NET since the first release: tell me about it! I fully concur. I don't deny this, nor excuse it. That said, I believe that once Microsoft decided that it was OK to break compatibility, they managed to improve upon lots of things which up until that point had become fairly painful on the traditional .NET Framework. You win some, you lose some, I guess?
- goto11 6y ago
  I believe Core stated as a minimal runtime for running Asp.net on other platforms than Windows. It was understood that this would not be fully compatible with the standard framework which was too coupled to Windows. But somewhere along the way it was decided that the core platform was the future and where all future improvement will happen. This leaves all .net framework code on a dead end platform. They will not be able to take advantage of any new improvement or even the new versions of C#. I don't think MS deliberately decided to break backwards compatibility in .net. It just sort of happened because the core project got out of control.
  - josteink 6y ago
    > It just sort of happened because the core project got out of control. A more accurate representation of events would be that .NET Core suddenly fueled a huge interest and growth in .NET as a platform which it hadn't seen in a long time (it was actually in decline!). Microsoft probably decided that for the overall, long-term health of the .NET platform it was more important to cater to these new users, than maintaining the status quo for the existing users, some which were already considering leaving ship. Looking back right now, it certainly looks like that was the right decision to make.
    - goto11 6y ago
      There is no doubt multi-platform support is great for ASP.Net. The problem is that MS has coupled everything. So to take advantage of the newest version of C# you have to migrate to the platform-independent framework which may not support all libraries you are currently using. This is absurd - why are these things coupled? If I maintain some internal tool using windows forms I have no desire to rewrite to support Unix - but if I don't, I am stuck on an abandoned platform. I think it comes down to Core was not conceived as the next version of .net but as an alternative runtime for a specialized purpose. So attention was not paid to decoupling or backwards compatibility or migration paths. And now we have a disaster which will dwarf the python 2/3 conundrum.
      - josteink 6y ago

ptx 6y ago

But if .NET Core was not meant to replace the .NET Framework, why is Microsoft doing just that with .NET 5? (Yes, the old framework will still exist after it's been replaced - the same way VB 6 still exists after being replaced by VB.NET and IE still exists after being replaced by Edge.)

josteink 6y ago
You are allowed to change your mind, aren't you? :) The goal for the initial .NET Core project was to have something cross-platform, modular and lightweight to build Linux-deployable cloud-services with. Once that reached a mature state, they could expand scope. And now, after .NET Core 3.x has landed, it has matured so much, that MS can see one single unified path forward which also includes some things which previously was only possible using the traditional .NET Framework (4.8). So now they are adding those use-cases to the "Core" package as well, without compromising on what .NET Core was supposed to deliver. I honestly don't see anything wrong with that.
- ptx 6y ago
  Right, but I think the complaint was that it was still immature and missing some use-cases covered by the old framework. Anyway, I do hope they succeed and the .NET 5 unification goes smoothly. I want those C# 9 features - but I also need some old third-party libraries to keep working.
  - ta17711771 6y ago
    Which ones, if you don't mind me asking out of curiosity?
    - ptx 6y ago
      Which features? Mostly data classes, a.k.a. records, and (from C# 8) non-nullable references. Kotlin has had these features for years and it makes things so much easier and cleaner IMHO.
      - jasonlhy 6y ago
        I believe they tried to keep the C# version independently from the framework version, so people can use the new C# version on a old .net framework. But things seem impossible for some new features, for example async steam just need new feature from core CLR. So after .C#8, they decide only to support it on .NET core
- goto11 6y ago
  The problem is it leaves all .net framework code on a dead-end platform. For all previous .net versions, code could be easily and safely upgraded to the next version because they were largely backwards compatible. But you can't easily upgrade existing code from 4.8 to 5. If you want to start a project from scratch, sure Core/5 is nice.
  - josteink 6y ago
    > For all previous .net versions, code could be easily and safely upgraded to the next version because they were largely backwards compatible. But you can't easily upgrade existing code from 4.8 to 5. As someone who has been working with .NET since the first release: tell me about it! I fully concur. I don't deny this, nor excuse it. That said, I believe that once Microsoft decided that it was OK to break compatibility, they managed to improve upon lots of things which up until that point had become fairly painful on the traditional .NET Framework. You win some, you lose some, I guess?
goto11 6y ago
I believe Core stated as a minimal runtime for running Asp.net on other platforms than Windows. It was understood that this would not be fully compatible with the standard framework which was too coupled to Windows. But somewhere along the way it was decided that the core platform was the future and where all future improvement will happen. This leaves all .net framework code on a dead end platform. They will not be able to take advantage of any new improvement or even the new versions of C#. I don't think MS deliberately decided to break backwards compatibility in .net. It just sort of happened because the core project got out of control.
- josteink 6y ago
  > It just sort of happened because the core project got out of control. A more accurate representation of events would be that .NET Core suddenly fueled a huge interest and growth in .NET as a platform which it hadn't seen in a long time (it was actually in decline!). Microsoft probably decided that for the overall, long-term health of the .NET platform it was more important to cater to these new users, than maintaining the status quo for the existing users, some which were already considering leaving ship. Looking back right now, it certainly looks like that was the right decision to make.
  - goto11 6y ago
    There is no doubt multi-platform support is great for ASP.Net. The problem is that MS has coupled everything. So to take advantage of the newest version of C# you have to migrate to the platform-independent framework which may not support all libraries you are currently using. This is absurd - why are these things coupled? If I maintain some internal tool using windows forms I have no desire to rewrite to support Unix - but if I don't, I am stuck on an abandoned platform. I think it comes down to Core was not conceived as the next version of .net but as an alternative runtime for a specialized purpose. So attention was not paid to decoupling or backwards compatibility or migration paths. And now we have a disaster which will dwarf the python 2/3 conundrum.
    - josteink 6y ago