.NET 5, .NET Standard, .NET Framework, .NET Core, ... now .NET 8. It's so confusing still.
.NET Core was renamed to .NET 5, which became the mainline .NET. .NET 8 is simply the latest version.
.NET Standard is intended to be a common layer to help bridge between .NET Framework and .NET Core and .NET 5+. It shouldn't be used outside of that context.
.NET Framework is the old, Windows-only .NET. It should not be used for new projects and should be migrated away from.
If you are writing a .NET library _and_ want it to work with very old deployments, then you also have to care about .NET Standard.
Like seriously: Windows XP -> Windows Vista -> Windows 7 -> Windows 8 -> Windows 10
or: xbox -> xbox 360 -> xbox one -> xbox series x/s
and a bunch of other things, like Azure Devops, which doesn't necessary have anything to do with Azure or Devops depending on how you use it. And their editor Visual Studio, and their other editor Visual Studio Code, which are not really related. IIRC, I also had to make a visual studio account in order to access the azure devops repository at my previous client, even though I don't use visual studio (the editor).
It's seriously like the Fast and Furious franchise.
They seem to be doing it for most of the microsoft products I can name, I wonder if there is a reason for it?
.NET Framework 4.8 will be longer supported than .Net 5, 6, 7 and maybe 8.
Just like their Xboxes.
Any version < 4 is out of security support. Only one version number starting with 4 remains in security support but you don't want to use it if you can use a higher version number. .NET 8 is new/fresh/current LTS. The rest of the "naming scheme" is dead weight.
It will presumably have longer support than .Net 8.
- Lack of cross-platform support (Windows only)
- Lack of Ahead-of-Time compilation options
- Worse performance
- Disappearing community support (many common/favorite libraries have already dropped 4.8 support and/or maintenance and are only looking at the .NET 5+ present; more do that every day and generally greenfield fresh/new libraries won't even consider 4.8 support or testing at all; this includes major first party libraries such as ASP.NET and Entity Framework, you cannot use the latest on 4.8 full stop)
- Worse and more expensive tooling (8 can be entirely command line driven including locally and cheaper and easier CI/CD installs and scripts, has great support not just in expensive IDEs like Visual Studio or Rider but also [cheap as free] VS Code and through LSP tools even options like vim/neovim/emacs in ways that 4.8 has mostly never supported)
Yes, there's definitely a shift in LTS strategies with .NET 5+. It isn't tied to Windows support lifetimes anymore, which has benefits too (much easier to deploy new versions; I will never miss the days of "we can't use that feature because management keeps putting off the Windows upgrade migration"). It is using a very similar strategy to NodeJS of twice a year releases with "even releases" being LTS supported for two years. That certainly can sound like a more complicated maintenance burden, but faster release cycles and shorter support windows generally mean fewer backward compatibility breaks and an easier upgrade from version to version.
The way I see 4.8 "long term support": the VB6 runtime is still technically "supported" in Windows 11 for long-tail backward compatibility but such long "support" doesn't mean VB6 is a good option for writing code today for Windows (or has been for a decade or more), and the VB6 IDE and compiler have not been supported since Windows XP. Fortunately, 4.8 isn't the VB6 of .NET because there are clear and easy upgrade paths, plenty of good migration tools, plenty of good reasons to migrate (performance! cross-platform!), many developers have happily migrated with no intention of going back, many new developers to .NET have enviably never experienced .NET <5 for many good reasons (Linux support!), and .NET 5+ is still unarguably .NET in every way that matters (the languages are the same, a vast majority of the base class library is the same or distinguishably better). This isn't a hard fork at this point, this is much more clearly "present and most useful" versus "outdated and legacy". But the sentiment of "don't use VB6" is still there for 4.8: if you are still working on 4.8 this year you probably better have the excuse of a large "brownfield" application with a huge legacy footprint. You are probably going to have a bad time doing it, you are going to have an increasingly uphill battle to get new developers to go back to 4.8, and the IDE and tools for supporting 4.8 are going to lose support soon (the ones that haven't already) and will only get more expensive and rube goldberg-like, to be trapped in VMs of older Windows versions and increasingly network isolated because of that.
We're on .NET 6 now, because it's LTS. But as of today, it has 1 more year of support (1)
.NET Framework 4.8 as an OS component, is actually supported for longer - no end date given (2).
Note that .NET Framework 4.6.2 is supported until Jan 12, 2027 - that's longer than .NET 6 and 7, and maybe 8
1) https://learn.microsoft.com/en-us/lifecycle/products/microso...
2) https://learn.microsoft.com/en-us/lifecycle/products/microso...
Confusing.
That means "stable" as in "it is not going to change".
But from a developer perspective, binding redirects, brrrrrr.... Also, source-level framework debugging tends to break every so often. It is obvious their focus is on the new .NET.
It was many a moon ago I even thought about .NET Framework. Not everyone might be so lucky, of course.
I would view it as a major, even terminal red flag if I was offered a job involving .NET Framework 4.8 or lower again.
.Net framework is the OG .Net and is windows specific. That stopped at v5 (I think)
.Net Core is the cross-platform reboot that was mostly a subset of framework, but not a proper subset.
If you wanted to write a library that worked across everything, you would target .Net standard, which wasn't a framework itself, but the intersection of APIs that existed everywhere.
Today, framework is discontinued, which makes standard kinda moot, and they dropped the "Core" branding. So as of .Net 6, that's pretty much all you'd write for new code.
If you have legacy code, then yeah you're back in that quagmire
.NET Framework Stopped at version 4.8
That's why .NET (formerly Core) could pick up at version 5.0
They had to handle a transition phase and as a .net dev at that time, it was surprisingly smooth
Seems like others are confused too: https://www.reddit.com/r/dotnet/comments/pqi891/net_maui_app...
- Open-source, portable, updated, default choice: .NET Core 1 2 3, .NET 5/6/7/8 - Included with Windows or Unity, frozen in time: .NET Framework 4 (don't use anything older) - Want to support both: .NET Standard (this is a subset that both can run)