about version

[yuankan1986]

Version 8.0.20 has three versions: 8.0.414, 8.0.317, 8.0.120, why?

[baronfel]

Because 8.0.20 is the version of the .NET Runtime, but there are also three in-support feature bands of the .NET SDK that versions of the Runtime is bundled with.

[yuankan1986]

Because 8.0.20 is the version of the .NET Runtime, but there are also three in-support feature bands of the .NET SDK that versions of the Runtime is bundled with.

sorry,i can't understand.
Ubuntu 24.04, use apt-get install dotnet-sdk-8.0，I get 8.0.119；why not 8.0.413?

[baronfel]

That's a separate issue - the Ubuntu maintainers choose to only distribute the 1xx series of SDKs. Microsoft does not ship packages for Ubuntu. If you want more recent feature bands you'll need to install the SDK through another pathway, like the dotnet-install scripts.

[mostynb]

How should someone choose between the 1xx/3xx/4xx series of dotnet8 SDKs? It is not obvious what the difference is.

[jozefizso]

@baronfel I work with .NET from the first beta releases in 2001. Frankly I have no idea how to wrap my head around the amount of SDK releases and which one is in-support and if we are using the latest patched versions.

And there's no documentation about this.

[KalleOlaviNiemitalo]

There is a table of .NET SDK feature bands at https://learn.microsoft.com/en-us/dotnet/core/porting/versioning-sdk-msbuild-vs, with end-of-support months, although not full dates.

[baronfel]

I totally get that it's a confusing space. It's my job to know it and I still find it byzantine sometimes!

As a rule of thumb, I want you to be on the latest SDK possible - we deliver new features, perf improvements, new analyzers, compiler codegen improvements, and so much more through the different 'feature bands' of the SDK, and 'newer' feature bands can always build applications and libraries that target 'older' .NET Runtimes. As a concrete example, it's 100% fully supported to use the .NET 10 RC2 SDK to build libraries and applications that target the net8.0 or net9.0 TargetFramework. This is always true - we want to encourage and make it easy for folks to update their tooling even if they don't update their projects.

However, how you get that SDK is very fragmented. Many Windows users are automatically updated through Visual Studio, which always bundles a single version of the .NET SDK that it is expressly intended to work against. Windows users may also get automatically updated by the Microsoft Update program, which the .NET SDK and .NET Runtime installers participate in. On macOS there's no Microsoft-supported automatic update mechanism, so many users either download .pkgs directly from us, or they use a tool like homebrew to manage their installations. On Linux the story is even more fragmented: some Linux distributions have the .NET SDK and .NET Runtime available as packages in their system package managers - but these packages are kept at the .100 series of SDKs. For users that want newer versions of the SDK, they use the dotnet-install scripts or other version-management mechanism (asdf, mise, dnvm, etc) to get and manage those versions.

This fragmented landscape, along with the Visual Studio support bands that @KalleOlaviNiemitalo mentioned are why we publish multiple releases of the .NET SDK with the 'same' .NET Runtime versions - we want whatever tooling version you use to bring along the latest version of the Runtime for security and performance reasons.

We're working on some tools in this space to make it easier to detect out of date SDKs, update outdated SDKs, and install/manage the SDKs and Runtimes you have installed on your machine - more on that hopefully quite soon.