Earlier articles in this ongoing series of “how to name things”:<p>- September 2016: Introducing .NET Standard (<a href="https://devblogs.microsoft.com/dotnet/introducing-net-standard/" rel="nofollow">https://devblogs.microsoft.com/dotnet/introducing-net-standa...</a>)<p>- May 2019: .NET Core is the Future of .NET (<a href="https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/" rel="nofollow">https://devblogs.microsoft.com/dotnet/net-core-is-the-future...</a>)<p>- May 2019: Introducing .NET 5 (<a href="https://devblogs.microsoft.com/dotnet/introducing-net-5/" rel="nofollow">https://devblogs.microsoft.com/dotnet/introducing-net-5/</a>)<p>(Yes, the last two are from the same month, even day. The second one is consistent with this article)<p>I may have missed a few episodes.
This is the most schizophrenic platform I've ever worked on. I've just spent an hour trying to make something work across the five different variants and web pipelines doing things underneath.<p>Edit: to be clear we have completely hung legacy stuff which is waiting resources (lots of $$$$ wasted) to port it to later versions of the frameworks because huge chunks of the ecosystem got abandoned by MS and the OSS developers who were supporting it.<p>On the positive side I'm getting paid danger money now.
This is good news for experienced .NET developers and newcomers alike. It marks the end of the journey from legacy .NET Framework to fully open source cross-platform .NET.<p>.NET Standard was confusing, and the ubiquitous TFMs in the early days were even more so. But all of those struggles where made to achieve a cross-runtime compatibility layer to make it easier to support both ecosystems. It was a Herculean effort by Microsoft, and they achieved it.<p>Now it's purpose has been served and as we move forward we can all just use the simple name of netX.Y, unless we're library authors that want to continue to support legacy .NET Framework as well.
Microsoft is making lots of performance improvements on .Net Core side. It seem to be lot faster than Java now. With .net core being open source and Cross Platform I think it is still not able to take Javas marketshare.
<a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>
As a primarily native-client dev who has developed for most major desktop and mobile platforms, I hope MS achieves it's goal of .NET being a truly solid cross-platform option, but in a way that enables clean and efficient native-code interop.<p>Having used C++, some insane hand-rolled solutions, PhoneGap/Cordova, Unity, and now Kotlin MPP, I know that the "cross-platform" dream is messy and fraught with disaster, but I've come to really appreciate C# and .NET for day-to-day client dev.
As someone who was somewhat out of the loop for a couple of years with regards to .NET/Core etc and the "Standard" thing, I had kind of wondered what all these new "Standard" options in Visual Studio meant and after a couple of hours of Googling it made sense.<p>I think there's a few folks out there who make a wee bit of a mountain out of a molehill when it comes to this "unification" effort by Microsoft to deliver I guess "the one .NET to rule them all".<p>Now sure it's been a wee bit painful (no less probably than for those working on .NET itself) to get to this stage, but .NET has been around for a lot of years, welded for most of its life to Windows and this transformation wasn't going to happen overnight. But having the "Standard" TFM bits has gone some way during this time to <i>mostly</i> ensure your code can be compiled an deployed to "any platform" albeit with some caveats and some warts.<p>I think .NET-5 is a reasonable step in the right direction. And for those of us working on .NET 4.x projects that still need to be looked after (I work on a pretty sizeable .NET 4.7 app) well MS will be supporting the "Windows .NET" for a good few years to come.<p>I should say that whilst .NET and Windows are my rent-paying tools-of-the-trade, I'm not a fanboi and have my own beefs and criticisms about MS's tooling decisions. Don't get me started about EF, especially Enum handling from back in the day.<p>And yes, sometimes (in fact many times) MS do somewhat cack-handedly mess up naming things which doesn't help.
Maybe Microsoft should give this whole thing a reboot. After many years working with .net but not following it closely last 2-4 years I'm hopelessly lost what's going on....
"net5.0-windows (and later net6.0-android and net6.0-ios). These TFMs represent OS-specific flavors of .NET 5 that include net5.0 plus OS-specific functionality."<p>Wait - net6.0-<platform> is actually net5.0?
The future of the .NET “Standard” .. it'll be a continously moving target, making it near impossible to clone ;]<p>Of course that'll mean developers are for ever playing catch-up, rewriting code at more expence.
I agree with others that the fast changing story on modularization (first everything comes as one package with .Net framework, then it's different packages, then it's all together again with .Net core 3), standardization (.Net framework -> .Net standard -> .Net core), makes it hard to feel like this is a <i>stable</i> platform, in the sense that you can understand the basic architecture of the platform and it will stay that way for some time, decades even...<p>I personally felt .Net standard was a great investment in making a standard platform that the community could contribute to, that would, of course, move slower than the giant monolith controlled by Microsoft... but nothing about .Net standard didn't mean you couldn't choose to use the giant monolith instead, it just guaranteed some semblance of stability if that was your preference.