6 ms·

.NET 5, .NET Standard, .NET Framework, .NET Core, ... now .NET 8. It's so confusing still.

rjbwork 3y ago
If you're doing any new work as of the past 3 years, it's just .NET. It's really not that confusing unless you're updating legacy software in which case you're probably quite embedded in the ecosystem already.
egeozcan 3y ago
I wanted to create an application. So apparently among the options are .net core blazor and MAUI blazor and their non-blazor versions. So many options with very confusing marketing. Seems like others are confused too: https://www.reddit.com/r/dotnet/comments/pqi891/net_maui_app_vs_net_maui_blazor_app/ https://www.reddit.com/r/dotnet/comments/pqi891/net_maui_app...
donny2018 3y ago
Starting from .NET 6 I think, it's pretty consistent. It's just .NET 6, 7, 8, etc.
- croes 3y ago
  Still confusing if can't simply switch to the most recent version or have legacy software. .NET Framework 4.8 will be longer supported than .Net 5, 6, 7 and maybe 8.
  - meibo 3y ago
    This is not unusual in Microsoft-land. If a tech stack or version is very widely adopted or heavily revamped in a new version, they will often support that old version for a very long time - see Windows 7.
    - croes 3y ago
      No problem with LTS but why the confusing name scheme. Just like their Xboxes.
      - WorldMaker 3y ago
        The name scheme was confusing only during the "overlap" period. At this point again you can strictly pay attention to version numbers: 8 > 7 > ... > 4 > 3 > ... 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.
        croes 3y ago
        Why don't I want to use .Net Framework 4.8? It will presumably have longer support than .Net 8.
        WorldMaker 3y ago
        - Lack of features - 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.
  - nightski 3y ago
    Every even release is LTS (including .NET 8 today). New projects should not use Framework at all. It's really not confusing at all.
    - SideburnsOfDoom 3y ago
      Yes, but that parent has a point: that new LTS is 3 years of support. Which is not that "long term". 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/microsoft-net-and-net-core https://learn.microsoft.com/en-us/lifecycle/products/microso... 2) https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework https://learn.microsoft.com/en-us/lifecycle/products/microso...
      - deleted 3y ago
        [deleted]
      - nightski 3y ago
        If you care about support, within 3 years you'll likely need to update dependencies as well which means a recompile. You might as well change your target at that time. Honestly the breaking changes have been pretty minimal lately and it's pretty trivial to upgrade.
    - croes 3y ago
      .Net 8 is supported 3 years, . Net Framework 4.8 presumably longer. Confusing.
      - custard42 3y ago
        .NET Framework is part of Windows. That means it is very stable and supported for a very long time. But it is also not possible to evolve it further. That is why the .NET team forked it to make .NET Core, which is cross platform and installs versions side by side. This is what evolved into .NET, most recently .NET 8.
  - moogly 3y ago
    > .NET Framework 4.8 It was many a moon ago I even thought about .NET Framework. Not everyone might be so lucky, of course.
    - SideburnsOfDoom 3y ago
      Yes, I'm in the good place now where I only have to think about version .NET 6 and up. 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.
topbanana 3y ago
All those terms are consigned to history except .NET They had to handle a transition phase and as a .net dev at that time, it was surprisingly smooth
bmitc 3y ago
It's actually pretty easy if you're new to .NET. If that's the case, it's just .NET 8 and forget about everything else. .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.
- sebazzz 3y ago
  Think of ".NET Standard" as "the common .NET Standard on which you can build cross-framework libraries".
  - bmitc 3y ago
    It is my understanding that it isn't recommend though anymore. In that it should only be used if you really want your library used in .NET Framework. My vague recollection is that it keeps you away from some of the benefits of the modern .NET.
klauserc 3y ago
Eh... since .NET 5 I feel that things have become simpler. If you are writing applications, there is really just the "modern" .NET to keep track of. Occasionally, you have to add "Core" to a Google search to not see results referencing old .NET framework APIs, but that's about it. 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.
deleted 3y ago
[deleted]
mardef 3y ago
It is confusing, but recently it's pretty straightforward .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
- SideburnsOfDoom 3y ago
  > .Net framework is the OG .Net and is windows specific. That stopped at v5 (I think) .NET Framework Stopped at version 4.8 That's why .NET (formerly Core) could pick up at version 5.0
mailund 3y ago
I've been thinking about this recently, Microsoft seem to consequently name things in the least intuitive way. 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?
ynx 3y ago
tl;dr: - 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)

If you're doing any new work as of the past 3 years, it's just .NET. It's really not that confusing unless you're updating legacy software in which case you're probably quite embedded in the ecosystem already.

egeozcan 3y ago

I wanted to create an application. So apparently among the options are .net core blazor and MAUI blazor and their non-blazor versions. So many options with very confusing marketing. Seems like others are confused too: https://www.reddit.com/r/dotnet/comments/pqi891/net_maui_app_vs_net_maui_blazor_app/ https://www.reddit.com/r/dotnet/comments/pqi891/net_maui_app...

donny2018 3y ago

Starting from .NET 6 I think, it's pretty consistent. It's just .NET 6, 7, 8, etc.

croes 3y ago
Still confusing if can't simply switch to the most recent version or have legacy software. .NET Framework 4.8 will be longer supported than .Net 5, 6, 7 and maybe 8.
- meibo 3y ago
  This is not unusual in Microsoft-land. If a tech stack or version is very widely adopted or heavily revamped in a new version, they will often support that old version for a very long time - see Windows 7.
  - croes 3y ago
    No problem with LTS but why the confusing name scheme. Just like their Xboxes.
    - WorldMaker 3y ago
      The name scheme was confusing only during the "overlap" period. At this point again you can strictly pay attention to version numbers: 8 > 7 > ... > 4 > 3 > ... 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.
      - croes 3y ago
        Why don't I want to use .Net Framework 4.8? It will presumably have longer support than .Net 8.
        WorldMaker 3y ago
        - Lack of features - 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.
- nightski 3y ago
  Every even release is LTS (including .NET 8 today). New projects should not use Framework at all. It's really not confusing at all.
  - SideburnsOfDoom 3y ago
    Yes, but that parent has a point: that new LTS is 3 years of support. Which is not that "long term". 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/microsoft-net-and-net-core https://learn.microsoft.com/en-us/lifecycle/products/microso... 2) https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework https://learn.microsoft.com/en-us/lifecycle/products/microso...
    - deleted 3y ago
      [deleted]
    - nightski 3y ago
      If you care about support, within 3 years you'll likely need to update dependencies as well which means a recompile. You might as well change your target at that time. Honestly the breaking changes have been pretty minimal lately and it's pretty trivial to upgrade.
  - croes 3y ago
    .Net 8 is supported 3 years, . Net Framework 4.8 presumably longer. Confusing.
    - custard42 3y ago
      .NET Framework is part of Windows. That means it is very stable and supported for a very long time. But it is also not possible to evolve it further. That is why the .NET team forked it to make .NET Core, which is cross platform and installs versions side by side. This is what evolved into .NET, most recently .NET 8.
- moogly 3y ago
  > .NET Framework 4.8 It was many a moon ago I even thought about .NET Framework. Not everyone might be so lucky, of course.
  - SideburnsOfDoom 3y ago
    Yes, I'm in the good place now where I only have to think about version .NET 6 and up. 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.

topbanana 3y ago

All those terms are consigned to history except .NET They had to handle a transition phase and as a .net dev at that time, it was surprisingly smooth

bmitc 3y ago

It's actually pretty easy if you're new to .NET. If that's the case, it's just .NET 8 and forget about everything else. .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.

sebazzz 3y ago
Think of ".NET Standard" as "the common .NET Standard on which you can build cross-framework libraries".
- bmitc 3y ago
  It is my understanding that it isn't recommend though anymore. In that it should only be used if you really want your library used in .NET Framework. My vague recollection is that it keeps you away from some of the benefits of the modern .NET.

klauserc 3y ago

Eh... since .NET 5 I feel that things have become simpler. If you are writing applications, there is really just the "modern" .NET to keep track of. Occasionally, you have to add "Core" to a Google search to not see results referencing old .NET framework APIs, but that's about it. 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.

deleted 3y ago

[deleted]

mardef 3y ago

It is confusing, but recently it's pretty straightforward .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

SideburnsOfDoom 3y ago
> .Net framework is the OG .Net and is windows specific. That stopped at v5 (I think) .NET Framework Stopped at version 4.8 That's why .NET (formerly Core) could pick up at version 5.0

mailund 3y ago

I've been thinking about this recently, Microsoft seem to consequently name things in the least intuitive way. 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?

ynx 3y ago

tl;dr: - 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)