3 ms·

> 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

> 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
  > And now we have a disaster which will dwarf the python 2/3 conundrum. Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was. At least .NET 5 will have compatible string-types once you've upgraded your projects :)
  - goto11 6y ago
    > Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was. Given that .net is much more entrenched than Python was 12 years ago, I think it going to take a lot longer! Frameworks like WebForms and WCF will not be ported, so projects depending on these will require massive rewrites. This a lot more work than fixing string encodings and putting parentheses after "print".
    - josteink 6y ago
      > Frameworks like WebForms and WCF not be ported WebForms is terrible and I see no reason for anyone to pull that monstrosity of a "I wish we had a VB/Windows WYSIWYG app-editor for the web" impedance-mismatch into a new codebase. Applications which haven't migrated off WebForms yet, probably have little to gain by moving to .NET Core anyway. WCF has been open-sourced[1] and ported (at least the client libraries) and you have separate community-projects[2] working on porting the rest of the stack to be compatible and usable with .NET Core. If the community really want's to go full WCF on the new stack, they are empowered to do so. [1] https://github.com/dotnet/wcf https://github.com/dotnet/wcf [2] https://github.com/CoreWCF/CoreWCF https://github.com/CoreWCF/CoreWCF
      - goto11 6y ago
        > WebForms is terrible Sure, but that is beside the point. You don't make legacy code disappear just by wishing it away.
  - deleted 6y ago
    [deleted]

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
> And now we have a disaster which will dwarf the python 2/3 conundrum. Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was. At least .NET 5 will have compatible string-types once you've upgraded your projects :)
- goto11 6y ago
  > Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was. Given that .net is much more entrenched than Python was 12 years ago, I think it going to take a lot longer! Frameworks like WebForms and WCF will not be ported, so projects depending on these will require massive rewrites. This a lot more work than fixing string encodings and putting parentheses after "print".
  - josteink 6y ago
    > Frameworks like WebForms and WCF not be ported WebForms is terrible and I see no reason for anyone to pull that monstrosity of a "I wish we had a VB/Windows WYSIWYG app-editor for the web" impedance-mismatch into a new codebase. Applications which haven't migrated off WebForms yet, probably have little to gain by moving to .NET Core anyway. WCF has been open-sourced[1] and ported (at least the client libraries) and you have separate community-projects[2] working on porting the rest of the stack to be compatible and usable with .NET Core. If the community really want's to go full WCF on the new stack, they are empowered to do so. [1] https://github.com/dotnet/wcf https://github.com/dotnet/wcf [2] https://github.com/CoreWCF/CoreWCF https://github.com/CoreWCF/CoreWCF
    - goto11 6y ago
      > WebForms is terrible Sure, but that is beside the point. You don't make legacy code disappear just by wishing it away.
- deleted 6y ago
  [deleted]