I don't see the problem with the last two you listed, seeing as right near the top of the article it says -
.NET 5 = .NET Core vNext
They are basically taking .NET Core and getting rid of the Core aspect of the name since it will be the only actively developed version of .NET going forward.
It's not THAT bad. You're conflating a bunch of stuff. If you're interested just take some time and read up on it. The roadmap is clearly explained on docs.microsoft.com.
With .NET 5 things are going back to a "check the version number" naming system though. 5 is greater than .NET Core 3.x, .NET Framework 4.x, and .NET Standard 2.x, you can pretty much forget what Core/Framework/Standard entirely mean as soon as you can upgrade to 5. (And the next version is .NET 6.) It's one version number left now.
(Also, DirectX tried to version number individual components at various points in its history so even DirectX "naming" isn't that straightforward at certain points in time in the past.)
Omfg, the hours I've wasted searching for netframework answers, and all the search results are netcore. Because search engines prefer newer, and nobody adds "framework" to their questions.
I've had the opposite problem more than once. ;-) When .Net Core 3.x was in development, OMG was it hard to actually find examples of how to do certain things.
At least .Net Core (soon 5) is easier to target containers (Docker) with.
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.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
MSFT Employee here who came in via last year’s jClarity acquisition (yes Microsoft now has a Java Engineering Group!). Oracle change the licensing terms on its Oracle JDK (which was the default JDK most of the world used) to something more commercial which some folks thought was it communicated well enough.
There are a ton of free in beer and free in use options. You can look at adoptopenjdk.net for the broadest community led one or azul Zulu for the one that’s been around since even before Oracle made their change
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.
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.
On the positive side I'm getting paid danger money now.
What do you mean by five different variants? Also, what are the chunks of the ecosystem that were abandoned? Web Forms? Silverlight? UWP?
Microsoft has shown an amazing ability to modernize and improve the platform without dragging baggage around from one version to the next.
We just took an ASP.NET MVC web app developed in 2005 for Windows/IIS and shipped it on linux using .NET core— the conversion took 1 developer just 2 days.
Trivial projects yeah. This is not a trivial project.
As for different variants. Two different http pipelines (classic, integrated), OWIN, one obsolete variant of OWIN, whatever is lurking inside .Net core now. WebAPI, MVC, bits of the remains of WCF floating around.
Abandoned bits: WCF, WWF, older OWIN pipelines, SignalR and a huge chunk of open source projects and commercial CLR packages.
SignalR is still supported. Though yes, modern "Core SignalR" is something of a rewrite compared to older versions of SignalR, though the biggest backwards incompatible changes are JS client side, not server side .NET side (most of that remains the same once you swap nuget packages), as they dropped the magic JS autogenerated client for a sometimes more sensible "Event Emitter" style client.
WWF has nothing in common with the other stuff?! It was also one of the shittier MS technologies.
Shipping software over decades is tricky: look at the alternatives: what web app from 2005 could you just run today? How has the platform developed over time? PHP, Perl, Python, Java, Ruby... No really clear winner there, IMO
We have a million line SaaS on .NET 4.7.2 running EF 5 that we can't upgrade to .NET Core.
We can't do it all in one big bang as it's too much effort and too risky. It will like just continue to rot. We're trying to break it up somewhat and write new parts in .NET Core, but it's an ugly reality staring us in the face.
At work, we sidestepped having to explicitly do a Python 2 -> 3 transition, because we were already rewriting the monolith as a bunch of microservices. Took 7 years.
The truly great thing about java is sun somehow created an ecosystem, a community. Probably by leading with specs, always, and not implementing anything but the core. So, you wind up with a real marketplace and a collaborative development effort. The variety of widely-accepted non-Sun solutions is an indicator.
Meanwhile, in microsoft-land... no spec, no standard. It's just "whatever MS does, that's the Thing." Nothing 3rd party is implemented because (a) no spec, and (b) MS has a nasty habit of cutting 3rd parties off at the knees. (Maybe because they're not happy with what 3rd parties develop, because... no spec.)
The result? Microsoft blinders. "If MS didn't invent it or publicize it at Build, it's no good."
So, you get the absolute ferment of java (and python, same factors, really) or... solutions by MS or MS vendors, which is more limited because a profitability case has to be made to lenders.
MS really did play catch-up with Java, which they were able to do because of the MS tax. Don't make any arguments based on technological superiority, 'cause there ain't none. Java (and the entire web, really) caught MS flat-footed. Bottomless pockets saved them.
golang isn't really a threat. It's a weak language with a very messy ecosystem. They don't even have proper versioning
figured out, not to mention a proper package manager.
C# is a much more powerful language than golang, with great monitoring and introspection tools. C# also has nuget (among others) for package management.
It capturing the minds of youth way faster than .NET did. Package management is an absolute mess on NET too. I was working on a project that had to work with old Mono versions, so it still used packages.config. Behold this mess: https://docs.microsoft.com/en-us/nuget/reference/packages-co...
> It capturing the minds of youth way faster than .NET did
It's because of hype. When analyzing things objectively, the unsubstantiated claims of the golang team quickly collapse. This is coming from someone who saw the mess that golang created in real production systems, which would not have happened in languages like Java and C#.
Mono isn't .NET. Using nuget in Visual Studio or IntelliJ Rider is a breeze.
"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."
I was surprised by this, too. I've spent the last 20 minutes researching; it seems every time I look away for more than a few minutes, Microsoft changes things up (then leaves nasty comments like didn't you read the FAQ or 'it was explained clearly, .net 5 is a separate language together and individually' https://forums.xamarin.com/discussion/177951/future-of-xamar...).
My reading of this is that Xamarin has been dropped from .NET 5 and moved to .NET 6, and Microsoft is hoping you don't notice.
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.
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.
I guess the opposite of Electron: a client written with the official framework of the platform (UWP for Windows, Cocoa for Mac, GTK or QT for Linux etc).
Also, a lot of the Xamarin stuff will be merging directly "out of the box" with .NET 6 next year. In particular, what used to be called Xamarin.Forms will be called MAUI [Multi-platform Application UI] starting with .NET 6, and the MAUI name and new namespaces (Xamarin.Forms => System.Maui, Xamarin.Essentials => System.Devices) seem to show greater investment/interest from Microsoft in making it first class moving forward.
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.
.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.
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.
I am not sure about the end of the journey. Lots of legacy .NET Framework code means I will continue targeting .NET Standard 2.0. That's why nobody used 2.1 - it did not support legacy framework. .NET 5 does not solve this problem. Just renaming .NET Core (3+1) to .NET 5 won't magically make legacy code portable.
Also, there is still very popular Unity 3D, that can target later framework, but will continue to run on the legacy one itself for a while.
My understanding is that Unity is hoping to catch up as soon as some of the final AOT stuff merges from Mono into .NET 6, so "for a while" in the case of Unity is now supposed to be a year or less (given Preview versions).
I fear it marks the beginning of a very long dark journey, where .net developers are forced to work on more and more obsolete software while looking with envy towards other platforms which are actually maintained.
The "core" migration is not a problem for short-lived startups, but .net is used a lot in business and enterprises. They don't rewrite their whole stack every two years but prefer an incremental approach. Since a lot of libraries will never be ported to core, a lot of enterprises will never migrate, since there will always be this critical internal app on web forms or whatever.
It is amazing that .net now runs on Linux, but it is a disaster that this platform change is tightly coupled to completely unrelated components like the C# compiler version. Developers on the framework now is stuck on an obsolete version of C# forever, cannot upgrade entity framework and so on.
C# attracted a lot of Java developers back when it got lambdas and Linq and async and whatnot, and Java seemed stuck in last century. Is it going to be the other way around in the future?
That's not my experience. Enterprises usually schedule far in advance budget specifically for the sole purpose of upgrades. Every product has a life of end support and projects to move to the next version are a reality in the enteprise market that brings a lot of money to the table.
For .NET it will be exactly the same.
I agree, probably even more polarizing than the Python 2/3 fiasco. All big applications in C# have been built on .Net Framework and migration to Core is non-trivial if you use any of the EOL technologies. OSS has mostly migrated by now, so on Framework you’re left with outdated dependencies that might have fixed security holes, but you cannot upgrade. Also we’re stuck with C# 7.3 as 8 requires .Net Core 3.
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 stable 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...
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.
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....
This is the "reboot announcement". Starting with .NET 5 there's only one .NET again that matters (though you'll hear lots of legacy support complaints for years to come). 5 is now the highest version number and the next version number is 6 like you would expect. There's no other versions you need to know unless you have to support legacy code (and there, it's probably time to reboot if you are supporting certain types of legacy code).
Well you missed a whole bunch of commotion. .Net 5 is the new .Net and you don’t need to worry about standard or core or 2.0, 2.1, 3.x, backward compatibility, etc.
If you start a new project after .Net5 is released in November, there will be little to nothing to worry about and you won’t have missed much of anything.
That sounds great! Will this have good VS Code support? Being a .net developer having used VS before mostly, I had lots of trouble a little over a year back building and referencing things with VS Code. It was easier to use Go and Python with VS code actually.
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.
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".
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 mostly ensure your code can be compiled an deployed to "any platform" albeit with some caveats and some warts.
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.
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.
And yes, sometimes (in fact many times) MS do somewhat cack-handedly mess up naming things which doesn't help.
In my experience it has become a Python 2 vs. Python 3 situation.
For those projects stuck on .NET 4x it's getting progressively harder to Google for relevant info on .NET Framework. With the switch back you will be trying to find info on .NET 5 and you'll turn up stuff for .NET 4.5 and you'll have to go out of your way to additionally search for .NET Core.
I feel like MS backtracked on what they initially said when they said .NET and .NET Core would continue to both be developed. Instead they sort of invented this loophole of saying well .NET Core is .NET now so we are continuing to develop .NET.
83 comments
[ 3.3 ms ] story [ 127 ms ] thread- September 2016: Introducing .NET Standard (https://devblogs.microsoft.com/dotnet/introducing-net-standa...)
- May 2019: .NET Core is the Future of .NET (https://devblogs.microsoft.com/dotnet/net-core-is-the-future...)
- May 2019: Introducing .NET 5 (https://devblogs.microsoft.com/dotnet/introducing-net-5/)
(Yes, the last two are from the same month, even day. The second one is consistent with this article)
I may have missed a few episodes.
.NET 5 = .NET Core vNext
They are basically taking .NET Core and getting rid of the Core aspect of the name since it will be the only actively developed version of .NET going forward.
Edit: found it--the "M" is for moniker.
"To better reflect this, we’ve updated the target framework names (TFMs)"
becomes "To better reflect this, we’ve updated the names"
.net (before core)
.netstandard 2.1
.net 5
what a joke. This coming from someone who used to work as dev in .NET
(Also, DirectX tried to version number individual components at various points in its history so even DirectX "naming" isn't that straightforward at certain points in time in the past.)
At least .Net Core (soon 5) is easier to target containers (Docker) with.
.Net framework (the same thing that MS always had)
A new named cross platform framework. Not just another .Net derivative.
And a new name for the standard. Something like the Common .Net API.
That would have pretty much eliminated all confusion.
Instead they went with
.Net Framework
.Net Core
.Net standard
.Net {version_num}
There are a ton of free in beer and free in use options. You can look at adoptopenjdk.net for the broadest community led one or azul Zulu for the one that’s been around since even before Oracle made their change
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
vs
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
That is hardly a fair comparison.
These benchmarks are more impressive.
Meanwhile here's a C# program that does not use PCRE2:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
On the positive side I'm getting paid danger money now.
> danger money
In my experience, these often go hand-in-hand. Also, never heard 'danger money' and absolutely love it, thanks.
Microsoft has shown an amazing ability to modernize and improve the platform without dragging baggage around from one version to the next.
We just took an ASP.NET MVC web app developed in 2005 for Windows/IIS and shipped it on linux using .NET core— the conversion took 1 developer just 2 days.
As for different variants. Two different http pipelines (classic, integrated), OWIN, one obsolete variant of OWIN, whatever is lurking inside .Net core now. WebAPI, MVC, bits of the remains of WCF floating around.
Abandoned bits: WCF, WWF, older OWIN pipelines, SignalR and a huge chunk of open source projects and commercial CLR packages.
It's a shit show it really is.
We can't do it all in one big bang as it's too much effort and too risky. It will like just continue to rot. We're trying to break it up somewhat and write new parts in .NET Core, but it's an ugly reality staring us in the face.
Was a waste of money and time.
Resume Driven Development.
they still playing catchup with java when the real threat was GO, now they are behind, and far far behind
The truly great thing about java is sun somehow created an ecosystem, a community. Probably by leading with specs, always, and not implementing anything but the core. So, you wind up with a real marketplace and a collaborative development effort. The variety of widely-accepted non-Sun solutions is an indicator.
Meanwhile, in microsoft-land... no spec, no standard. It's just "whatever MS does, that's the Thing." Nothing 3rd party is implemented because (a) no spec, and (b) MS has a nasty habit of cutting 3rd parties off at the knees. (Maybe because they're not happy with what 3rd parties develop, because... no spec.)
The result? Microsoft blinders. "If MS didn't invent it or publicize it at Build, it's no good."
So, you get the absolute ferment of java (and python, same factors, really) or... solutions by MS or MS vendors, which is more limited because a profitability case has to be made to lenders.
MS really did play catch-up with Java, which they were able to do because of the MS tax. Don't make any arguments based on technological superiority, 'cause there ain't none. Java (and the entire web, really) caught MS flat-footed. Bottomless pockets saved them.
It's because of hype. When analyzing things objectively, the unsubstantiated claims of the golang team quickly collapse. This is coming from someone who saw the mess that golang created in real production systems, which would not have happened in languages like Java and C#.
Mono isn't .NET. Using nuget in Visual Studio or IntelliJ Rider is a breeze.
Wait - net6.0-<platform> is actually net5.0?
My reading of this is that Xamarin has been dropped from .NET 5 and moved to .NET 6, and Microsoft is hoping you don't notice.
https://devblogs.microsoft.com/dotnet/announcing-net-5-previ...
This announcement was made in a post announcing a preview release instead of its own post, so I can see why people missed it.
https://devblogs.microsoft.com/dotnet/the-future-of-net-stan...
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.
.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.
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.
Also, there is still very popular Unity 3D, that can target later framework, but will continue to run on the legacy one itself for a while.
The "core" migration is not a problem for short-lived startups, but .net is used a lot in business and enterprises. They don't rewrite their whole stack every two years but prefer an incremental approach. Since a lot of libraries will never be ported to core, a lot of enterprises will never migrate, since there will always be this critical internal app on web forms or whatever.
It is amazing that .net now runs on Linux, but it is a disaster that this platform change is tightly coupled to completely unrelated components like the C# compiler version. Developers on the framework now is stuck on an obsolete version of C# forever, cannot upgrade entity framework and so on.
C# attracted a lot of Java developers back when it got lambdas and Linq and async and whatnot, and Java seemed stuck in last century. Is it going to be the other way around in the future?
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.
Of course that'll mean developers are for ever playing catch-up, rewriting code at more expence.
If you start a new project after .Net5 is released in November, there will be little to nothing to worry about and you won’t have missed much of anything.
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".
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 mostly ensure your code can be compiled an deployed to "any platform" albeit with some caveats and some warts.
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.
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.
And yes, sometimes (in fact many times) MS do somewhat cack-handedly mess up naming things which doesn't help.
For those projects stuck on .NET 4x it's getting progressively harder to Google for relevant info on .NET Framework. With the switch back you will be trying to find info on .NET 5 and you'll turn up stuff for .NET 4.5 and you'll have to go out of your way to additionally search for .NET Core.
I feel like MS backtracked on what they initially said when they said .NET and .NET Core would continue to both be developed. Instead they sort of invented this loophole of saying well .NET Core is .NET now so we are continuing to develop .NET.