.NET May 2024 Update - .NET 8.0.5, NET 7.0.19, .NET 6.0.30

[rbhanda]

.NET May 2024 Update

Release Notes

• 8.0.5
• 7.0.19
• 6.0.30

.NET 7.0 reaches end of support today

Status

Asset Type	8.0.5	7.0.19	6.0.30	Notes
Installers/Binaries	✅	✅	✅
Snaps	✅	✅	✅
Linux Packages (Microsoft distribution)			The list below refers to the Microsoft-provisioned feeds (packages.microsoft.com) and does not in any way represent direct availability in distros (eg RHEL, Fedora).
Centos 7	NA	✅	✅
Centos 8	✅	✅	✅
Debian 10	✅	✅	✅
Debian 11	✅	✅	✅
Debian 12	✅	✅	✅
Fedora 37	✅	✅	✅
Fedora 38	✅	✅	✅
Fedora 39	✅	✅	✅
Fedora 40	✅	✅	✅
OpenSUSE 15	✅	✅	✅
Ubuntu 20.04	✅	✅	✅
Ubuntu 22.04	✅	✅	✅
Ubuntu 23.04	✅	✅	✅
Ubuntu 24.04	✅	✅	✅

Issues

Please report any issues you find either by responding to this issue, creating a new issue or creating a new issue in one of the following repos:

• ASP.NET Core: dotnet/aspnetcore
• Entity Framework Core: dotnet/efcore
• .NET CLI/SDK dotnet/sdk
• .NET runtime dotnet/runtime
• Winforms: dotnet/winforms
• WPF: dotnet/wpf
• NuGet: nuget/home
• Containers: dotnet/dotnet-docker
• Winget: microsoft/winget-pkgs

Known Issues

[mattzink]

Is the full changelog link for the 7.0.19 release supposed to be comparing v6.0.29 -> v7.0.19? I guess I was expecting 7.0.18 -> 7.0.19?
https://github.com/dotnet/core/releases/tag/v7.0.19

[antmeehan]

There seems to be a change in the Central Package Management behaviour in SDK 8.0.300 around the existence of Directory.Packages.props file. We had one in our solution but it didn't have anything defined, ie:

<Project>
</Project>

dotnet restore was happy under previous SDK versions, but now under 8.0.300 it starts complaining about the incorrect use of Central Package Management (as if it is enabled), eg:

error NU1008: Projects that use central package version management should not define the version on the PackageReference items but on the PackageVersion items

Deleting the Directory.Packages.props has fixed the issue.

[Serge-N]

Publish the blog too .

[andreaskromann]

@antmeehan it seems to be this change: NuGet/NuGet.Client#5572

[libreo-abrettschneider]

Is it possible that this update changed the way code style analyzers work at least for 8.0.5? Out of sudden analyzers that didn't trigger before are now producing warnings or in our case errors preventing our build from working even so there weren't any changes. e.g.: error IDE0100: Remove redundant equality

[SusanBradley]

Can we get a priority on publishing the blog on the day that updates are released? https://devblogs.microsoft.com/dotnet/May-2024-updates/ that's MIA. I'm not a developer, I'm a patcher and I rely on the communication from the .NET blog to know what updates I should be expecting.

[mairaw]

@SusanBradley the blog post is now live athttps://devblogs.microsoft.com/dotnet/dotnet-and-dotnet-framework-may-2024-servicing-updates/

[SusanBradley]

@mairaw https://support.microsoft.com/en-us/topic/-net-6-0-update-may-14-2024-kb5038350-a08fa6e5-7c7e-4ecb-a15e-268507cd39ab that says that the .net 6 also has security updates, not just 7 and 8?

[rbhanda]

@mairaw https://support.microsoft.com/en-us/topic/-net-6-0-update-may-14-2024-kb5038350-a08fa6e5-7c7e-4ecb-a15e-268507cd39ab that says that the .net 6 also has security updates, not just 7 and 8?

Hello, My apologies for the wrong details in the https://support.microsoft.com/en-us/topic/-net-6-0-update-may-14-2024-kb5038350-a08fa6e5-7c7e-4ecb-a15e-268507cd39ab. I have submitted a request to update this to reflect that 6.0 is a non security release

[Talouv-work]

As @antmeehan and @andreaskromann point out with NuGet/NuGet.Client#5572, I think it's worth noting that the default value of <ManagePackageVersionsCentrally /> has essentially changed such that whenever a file called Directory.Packages.props is present, the default value is now true (8.0.300) as opposed to false (prior to 8.0.300).

This was in fact a breaking change for us, because some of our legacy projects in our mono repository haven't been migrated to use the centralized package management, causing some of our builds to fail when building with the 8.0.300 SDK. We relied on the default value and using a more specific Directory.Build.props to ensure that these legacy projects did not use the central nuget package versioning.

Now, for anyone reading this, it's easily fixed by explicitly setting <ManagePackageVersionsCentrally>false</ManagePackageVersionsCentrally> in the Directory.Build.props file where you do not want to use CPM, but it is indeed something you MUST do before upgrading the dotnet SDK.

[pebezo]

Any reason why 8.0.4 or 8.0.5 is not listed here https://hub.docker.com/_/microsoft-dotnet-runtime ?

[lbussell]

Any reason why 8.0.4 or 8.0.5 is not listed here https://hub.docker.com/_/microsoft-dotnet-runtime ?

@pebezo The images are up to date, but the syndication from the Microsoft Asset Registry to DockerHub is currently not working. See dotnet/dotnet-docker#5327.

You can view the latest tags on MAR: https://mcr.microsoft.com/product/dotnet/runtime/tags

[bording]

Why did this release include the 8.0.300 SDK but the matching Visual Studio 17.9.7 update shipped with 8.0.205?

If I install 8.0.300 manually, it doesn't work properly in Visual Studio because it looks like the compiler version is too old, causing the SDK analyzers to not work.

For example:

The analyzer assembly 'C:\Program Files\dotnet\sdk\8.0.300\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CodeStyle.dll' references version '4.10.0.0' of the compiler, which is newer than the currently running version '4.9.0.0'.	ServiceControl.Audit.Persistence.SagaAudit	C:\Program Files\dotnet\sdk\8.0.300\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CodeStyle.dll

We currently have our CI builds set up to pick up the latest SDK, so this results in us having failing builds due to the analyzers in the updated SDK finding more cases of triggering patterns, but then us not being able to see them locally in Visual Studio and apply fixers.

It also appears the compiler in the 8.0.300 SDK has a new language breaking change that has impacted us as well, and it's a pain to figure out what's going on when I can't use the matching SDK in Visual Studio.

[OronDF343]

The blog post no longer contains links to the list of actual non-security changes in the release. Previously, there were links to the merged PRs in each repo, which wasn't ideal but at least was useful. Now, I have no easy way to see the list of actual changes without going to each repo and manually searching the PRs by milestone.

Please reconsider this change in communication, and ideally consider a way to list all of the changes in a simple list. Thanks

[leecow]

Can we get a priority on publishing the blog on the day that updates are released? https://devblogs.microsoft.com/dotnet/May-2024-updates/ that's MIA. I'm not a developer, I'm a patcher and I rely on the communication from the .NET blog to know what updates I should be expecting.

@SusanBradley - the May blog URL is https://devblogs.microsoft.com/dotnet/dotnet-and-dotnet-framework-may-2024-servicing-updates/ and looks like it was posted on the 15th. Not sure why it was late - will look into that.

[leecow]

Why did this release include the 8.0.300 SDK but the matching Visual Studio 17.9.7 update shipped with 8.0.205?

@bording - The May Updates included releases for 8.0.105, 8.0.205, and 8.0.300. Way back in the beginnings of .NET Core, we needed to figure out how to support new versions of Visual Studio along with new features in shared tools, such as compilers and analyzers. We refer to the first digit of the 'patch version' as the feature band. Sometimes a new feature band will include updates that effect backward compatibility.

To help know what .NET goes with what VS, we include the mappings in detailed release metadata. This can be seen as a top-level index that references each version channel (8.0 example). This file includes the VS mapping info, for example ...

                    "version": "8.0.205",
                    "version-display": "8.0.205",
                    "runtime-version": "8.0.5",
                    "vs-version": "17.9.7",
                    "vs-mac-version": "",
                    "vs-support": "Visual Studio 2022 (v17.9)",
                    "vs-mac-support": "",
                    "csharp-version": "12.0",
                    "fsharp-version": "8.0",
                    "vb-version": "16.9",

where vs-version indicates which VS update includes this particular SDK and Runtime, and vs-support, which indicates the supported VS minor version.

Hopefully this info helps with your update automation.

[leecow]

The blog post no longer contains links to the list of actual non-security changes in the release. Previously, there were links to the merged PRs in each repo, which wasn't ideal but at least was useful. Now, I have no easy way to see the list of actual changes without going to each repo and manually searching the PRs by milestone.

Please reconsider this change in communication, and ideally consider a way to list all of the changes in a simple list. Thanks

@rbhanda - please take a look.

[mairaw]

And the VS support info perhaps can be more easily consumed on the dot.net site
https://dotnet.microsoft.com/en-us/download/dotnet/8.0

[ghost]

Can we have link to what's the new feature released in 8.0.300, compared to 8.0.205, it should be a new feature release, so what's the new feature?

[mrahl]

Did 8.0.5 change the GC characteristics? Nothing mentioned in the release notes. But as we're rolling out updated containers we see increased Gen0 and Gen1 sizes as well as longer GC pauses, while Gen2 and LOH are decreasing. See image below. This is averages across thousands of instances that progressively get the new version, so the slope over time is explained as the change in mix of 8.0.4 based containers to 8.0.5 based containers.

[leecow]

Did 8.0.5 change the GC characteristics?

I see dotnet/runtime#100575 included in 8.0.5.

@Maoni0 can you have a look at the above?

[leecow]

Can we have link to what's the new feature released in 8.0.300, compared to 8.0.205, it should be a new feature release, so what's the new feature?

This versioning is primarily to enable new tooling work share with Visual Studio (ie compilers, analizers, msbuild, etc) to move forward with new versions of VS, though impactful SDK changes do sometimes also come into play.

@marcpopMSFT - who could help work out a good way to get this information into release notes or some other location?

[marcpopMSFT]

CC @baronfel in case he has any better idea on how to track/document this.
Typically, the SDK feature band releases are mostly about updates of the VS tooling (ie updates to nuget, msbuild, roslyn, razor, vstest, etc) to ensure the SDK matches what ships in VS. Those tool updates can have features in them but we rely on individual teams to document and call out any new features (for example, nuget package search was introduced in 8.0.200).

For the SDK, we typically update the .net 9 release notes with new features (even if those features ship in the feature band SDKs) to reduce the release costs. Looking over PRs into the 8.0.3xx branch, there are a few minor quality of life improvements and some container changes. Everything else in codeflow.

[baronfel]

Different repos/tech have different approaches here. The Containers tech has dedicated release notes in the SDK repo that are tracked per-SDK Release, while the F# team has per-component release notes markdown files that are currently published to community run sites like https://fsharp.github.io/fsharp-compiler-docs/release-notes/Language.html. I think from a process perspective the first step is having some kind of per-component changelog tracking happening as changes are made in the repo, and then aggregating those periodically.

[mrahl]

Did 8.0.5 change the GC characteristics?

I see dotnet/runtime#100575 included in 8.0.5.

@Maoni0 can you have a look at the above?

Apologies, this was most likely a false alarm. Averages are now returning to the same as before so I think it was simply because the rolling upgrade of course also means a rolling restart of all containers:

[chrispearson-cg]

Is it possible that this update changed the way code style analyzers work at least for 8.0.5? Out of sudden analyzers that didn't trigger before are now producing warnings or in our case errors preventing our build from working even so there weren't any changes. e.g.: error IDE0100: Remove redundant equality

We are also seeing this issue. We had one team member seeing this behaviour and the only difference we saw was the version of Visual Studio I was on 17.9.6 they were on 17.10. As soon as I also updated I got the same error.

An example error is:
if (expectedPattern.IsMatch(contents) == false)

Whilst this could be if(!expectedPattern.IsMatch(contents) which passes the check, the former is much harder to miss the intent.

dotnet --list-sdks
2.2.207 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
6.0.421 [C:\Program Files\dotnet\sdk]
8.0.300 [C:\Program Files\dotnet\sdk]

[nckl]

Is it possible that this update changed the way code style analyzers work at least for 8.0.5? Out of sudden analyzers that didn't trigger before are now producing warnings or in our case errors preventing our build from working even so there weren't any changes. e.g.: error IDE0100: Remove redundant equality

Since this release my CIDC has been broken for our aspnet application. CSHTML files now have build errors that don't make any sense. Of all the build errors its just cshtml files.

for example :

<div render-if="!@isUpdate" class="col-md-2"> has a build error error CS0201: Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement

isUpdate is defined above in a code block.

Using 8.0.301 doesnt help, has the same behaviour. For now I have pinned my pipeline image to mcr.microsoft.com/dotnet/sdk:8.0.204 but I have yet to figure out how to get a dev container with the 8.0.204 sdk

[leecow]

@wtgodbe, can you have a look at the comment above? Starting with you since @nckl is seeing the break in aspnetcore.

[wtgodbe]

dotnet/aspnetcore#54763 was the only analyzer change we took for 8.0.5, but it's not clear to me how that could be related (CC @JamesNK). If it's not that, it seems more likely to be a change in dotnet/roslyn-analyzers

[Ritika-Poddar]

Why did this release include the 8.0.300 SDK but the matching Visual Studio 17.9.7 update shipped with 8.0.205?

If I install 8.0.300 manually, it doesn't work properly in Visual Studio because it looks like the compiler version is too old, causing the SDK analyzers to not work.

For example:

The analyzer assembly 'C:\Program Files\dotnet\sdk\8.0.300\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CodeStyle.dll' references version '4.10.0.0' of the compiler, which is newer than the currently running version '4.9.0.0'.	ServiceControl.Audit.Persistence.SagaAudit	C:\Program Files\dotnet\sdk\8.0.300\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CodeStyle.dll

We currently have our CI builds set up to pick up the latest SDK, so this results in us having failing builds due to the analyzers in the updated SDK finding more cases of triggering patterns, but then us not being able to see them locally in Visual Studio and apply fixers.

It also appears the compiler in the 8.0.300 SDK has a new language breaking change that has impacted us as well, and it's a pain to figure out what's going on when I can't use the matching SDK in Visual Studio.
@bording were you able to resolve this? I am also getting same error after manully installing 8.0.300 sdk.

[Arauf2]

FYI, I am trying to install aspnetcore-runtime 8.0 on an almalinux image, and it appears the repo (https://packages.microsoft.com/config/alma/9/packages-microsoft-prod.rpm) is missing:
dotnet-runtime-deps-8.0-8.0.1-1.x86_64

I followed instructions here: https://learn.microsoft.com/en-us/linux/packages
and it appears that method is not necessary anymore, e.g: https://learn.microsoft.com/en-us/dotnet/core/install/linux-rhel still results in this:

microdnf install aspnetcore-runtime-8.0

aspnetcore-runtime-8.0-8.0.5-1.el9_4.x86_64 dotnet-host-8.0.5-1.el9_4.x86_64 dotnet-hostfxr-8.0-8.0.5-1.el9_4.x86_64 dotnet-runtime-8.0-8.0.5-1.el9_4.x86_64 libicu-67.1-9.el9.x86_64

On an amazonlinux-2023 image using the package method (https://packages.microsoft.com/config/amazonlinux/2023/packages-microsoft-prod.rpm), these are installed:

dotnet-host-8.0.1-1.x86_64 dotnet-hostfxr-8.0-8.0.1-1.x86_64 dotnet-runtime-deps-8.0-8.0.1-1.x86_64 dotnet-runtime-8.0-8.0.1-1.x86_64 aspnetcore-runtime-8.0-8.0.1-1.x86_64

I am also curious as to why an identical command, aside from the baseOS differences, installs 8.0.1-1 vs 8.0.5-1. I guess that also means the repo is technically missing
dotnet-runtime-deps-8.0-8.0.5-1.x86_64, given the versions should match.

@rbhanda, any ideas for next step?

[rbhanda]

closing in favor of #9390

[Arauf2]

@rbhanda, shall I open up an "issue" for my comment above? Thanks!