[james_s_tayler]

Does C# rely on VS? MSBuild is separate from VS and you can use Rider (yay!) or VSCode instead of VS.

The ecosystem is definitely growing in the last 5 years too since open source has been embraced by MS and the community.

The major rewrite of .NET -> .NET Core and then now renaming it back to .NET again is good in that it's a much better framework now, bad in that it's turning out like Python 2 vs Python 3. Huge projects just can't upgrade, so old .NET Framework stuff is sticking around longer than it should.

[lstamour]

Generally speaking, C# relies on either third-party implementations like http://www.omnisharp.net or Microsoft distributions, which on Windows is largely distributed via Visual Studio Downloads page, including the Tools for Visual Studio package: https://visualstudio.microsoft.com/downloads/ Are there other releases of msbuild, for example? Yes: https://github.com/dotnet/msbuild/releases But are they separate from releases of Visual Studio? No, as the release notes indicate. If you want to live on the bleeding edge of .NET development -- and I do recommend this -- you'll end up in the Preview channel of Visual Studio: https://visualstudio.microsoft.com/vs/preview/ and if you want to use Visual Studio Code instead, welcome to OmniSharp or similar "mostly compatible" solutions. It's totally fine until it's not, and it's definitely not portable or open enough -- yet. I look forward to the day when Visual Studio is fully open source because they can include subscriptions on top or something. That'll be the day when VS and VS Code could begin to merge a bit, at least for development on Microsoft platforms. But that hasn't happened yet, and they're rebuilding Visual Studio in Eclipse on other platforms to better support cross-platform development the same way Rider supports other platforms for JetBrains IDEs. It's a stop-gap until the fully-open-source versions of VS and VS Tools are finally available. I suspect they're waiting for .NET 5 or later, at this point...

They're undoing the split between Core and .NET Framework by suggesting that they'll ship both within .NET 5 using shims or implementations of drop-in replacements for .NET Framework code to use. Imagine if after dropping Python 2 support there was a mode that scanned for Python 2 code and enabled it again, on a file-by-file basis, to work with newer Unicode strings using some kind of translation layer in the runtime. That's kind of what's happening here, I think, but maybe more lightweight than suggested. Legacy .NET Framework code still deprecated, but interoperability libraries will ship as part of the runtime or SDK, will have some amount of shims available. I haven't followed the details closely enough to say more than this, though. I last looked into it a few months ago.

[tester756]

As far as I know - there will be those frameworks to select:

>net5.0

>net5.0-windows

>net5.0_something

So you can use "pure" "net5.0" on Linux and generally cross-platform software meanwhile still be able to use old .NET FrameworkX winforms/wpf on "net5.0-windows".