.NET February 2025 Update - .NET 9.0.2 and .NET 8.0.13

[victorisr]

.NET February 2025 Update

Release Notes

• 9.0.2
• 8.0.13

Status

Asset Type	9.0.2	8.0.13	Notes
Installers/Binaries	✅	✅
Container Images (Linux)	✅	✅
Container Images (Windows)	✅	✅
Winget Packages
Linux Installers (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).
Debian 12	✅	✅
Fedora 40	✅	✅
Fedora 41	✅	✅
OpenSUSE 15	✅	✅
Oracle 8	✅	✅
Oracle 9	✅	✅
Ubuntu 20.04	✅	✅
Ubuntu 22.04	✅	✅
Ubuntu 24.04	✅	✅
Ubuntu 24.10	✅	✅
✅

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

[splatteredbits]

https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json lists 8.0.406 as the latest SDK, but https://builds.dotnet.microsoft.com/dotnet/release-metadata/8.0/releases.json still lists 8.0.405 as the latest SDK and doesn't have any entries for 8.0.406. Please fix ASAP, as our tooling to auto install .NET versions because of the mismatch.

Also, please update processes to update the per-release releases.json metadata before updating the releases-index.json file to mitigate this happening in the future.

[rbhanda]

https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json lists 8.0.406 as the latest SDK, but https://builds.dotnet.microsoft.com/dotnet/release-metadata/8.0/releases.json still lists 8.0.405 as the latest SDK and doesn't have any entries for 8.0.406. Please fix ASAP, as our tooling to auto install .NET versions because of the mismatch.

Also, please update processes to update the per-release releases.json metadata before updating the releases-index.json file to mitigate this happening in the future.

I have purged CDN cache and the issue should be resolved.

[mstefarov]

The ".NET February 2025 Blog" link is broken.

The correct URL is https://devblogs.microsoft.com/dotnet/dotnet-and-dotnet-framework-february-2025-servicing-updates/

[bengavin]

Any chance we can include any new dotnet run first-class arguments as potential breaking changes? This one has broken our automated builds:

dotnet/sdk#45740

I realize it's not, technically, a breaking change, as one can't possibly account for everyone's use of the commands and custom argument handling and whatnot, but knowing that a new command line argument has been introduced in an update would have helped us track this down faster. :)

[baronfel]

@bengavin that's our fault - we usually have a documentation-tracking label that we use to mark issues/PRs that need more docs that we then write as part of the release process. I've added that label to the original issue and logged dotnet/docs#44867 to track getting those docs written - we'll get that done ASAP. Apologies for the disruption here.

If you want to future-proof you usage of run to the maximum extent, you should pass all arguments that you want to go directly to your application after a -- token - this is a common POSIX signal for "don't try to interpret anything after this and instead pass it directly to my app". This might look something like

> dotnet run -c Release -- -e mydata

In this case -e mydata would be passed directly to the project being run as CLI arguments.

[teo-tsirpanis]

Are all NuGet packages now going to always get a new version every month? Nothing changed to System.Speech for example and yet it got both a 9.0.1 and a 9.0.2. Bad idea if you ask me.

[doivosevic]

The 8.0.13 x64 Windows link is broken. I get 404 https://download.visualstudio.microsoft.com/download/pr/bd44cdb8-dcac-4f1f-8246-1ee392c68dac/ba818a6e513c305d4438c7da45c2b085/dotnet-sdk-8.0.406-win-x64.exe

[seantleonard]

For this release, 2025-02 .NET 8.0.13 Update for x64 Client (KB5052978), I am consistently experiencing Windows Update installation errors: Install error - 0x80070643. Is there any way to get more details for why this failure is occurring? Multiple "retries" and system restarts don't resolve the issue.

[mairaw]

The 8.0.13 x64 Windows link is broken. I get 404 https://download.visualstudio.microsoft.com/download/pr/bd44cdb8-dcac-4f1f-8246-1ee392c68dac/ba818a6e513c305d4438c7da45c2b085/dotnet-sdk-8.0.406-win-x64.exe

the link works for me. is still not working for you?

[mairaw]

The ".NET February 2025 Blog" link is broken.

The correct URL is https://devblogs.microsoft.com/dotnet/dotnet-and-dotnet-framework-february-2025-servicing-updates/

where do you see this link?

[osexpert]

I have a problem:

Take the Linux Runtime Binaries x64
https://download.visualstudio.microsoft.com/download/pr/a15e92d8-e1db-402c-b06d-b6dcf7ad58eb/8c4233bceadcf8f57b40f64aceda69f7/dotnet-runtime-9.0.2-linux-x64.tar.gz

Inside there is System.Runtime.Serialization.Formatters.dll
In ILSpy:
[assembly: AssemblyVersion("8.1.0.0")]
[assembly: AssemblyFileVersion("9.0.225.6610")]
104KB

When publish non-self-contained, this file is being used instead if the one from here:
https://www.nuget.org/packages/System.Runtime.Serialization.Formatters/9.0.2
In ILSpy:
[assembly: AssemblyVersion("9.0.0.0")]
[assembly: AssemblyFileVersion("9.0.225.6610")]
133KB

This is all very confusing. Why do the release 9.0.2 include a file with assembly version 8.1.0.0?
And it would be fine if it would work, but it fails:
Could not load file or assembly 'System.Runtime.Serialization.Formatters, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

If manually copying the file from the nuget, it works.

Not sure if this is the right place to ask, it may not be related to this at all. Thanks.
Edit: maybe the runtime is ment to include an old versioned file, for some reason. Maybe the real problem is something with nuget, not overwriting/using the newer file from the included package, maybe because the package seems unused because of the BinaryFormatter magical mapping happening under the hood?
Edit2: I wish the System.Runtime.Serialization.Formatters.dll would contain something that the runtime did not, so it could be referenced by code to make it "stay" and not look completely unused...