dotnet
.NET June 2025 Update - .NET 8.0.17 and .NET 9.0.6
.NET June 2025 Update
Release Notes
Status
| Asset Type | 9.0.6 | 8.0.17 | 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
.NET 8.0.17 & .NET 9.0.6 Breaking Change
Breaking Change: UseForwardedHeaders middleware now always checks ForwardedHeadersOptions.KnownNetworks and ForwardedHeadersOptions.KnownProxies
UseForwardedHeaders middleware now always checks ForwardedHeadersOptions.KnownNetworks and ForwardedHeadersOptions.KnownProxies. Because both KnownNetworks and KnownProxies default to Loopback this means deployed applications may fail to apply X-Forwarded-* headers resulting in properties like scheme and host not being updated which can have side-effects e.g. UseHttpsRedirection() might always see http and always redirecting the request.
The recommended fix is to set the KnownNetworks and KnownProxies values to the appropriate values. See https://learn.microsoft.com/aspnet/core/host-and-deploy/proxy-load-balancer for more details on using proxies and UseForwardedHeaders(). Alternatively, if you are fine accepting X-Forwarded-* headers from any source, which introduces security vulnerabilities, you can clear the KnownNetworks and KnownProxies properties.
There is an issue with the .NET 8 linux x64 tar.gz package (https://aka.ms/dotnet/LTS/dotnet-sdk-linux-x64.tar.gz).
Namely the release version is 8.0.411 . However inside the tar.gz package the folder structure is as follows:
├── host │ └── fxr │ └── 8.0.16 ├── packs │ ├── Microsoft.AspNetCore.App.Ref │ │ └── 8.0.16 │ ├── Microsoft.NETCore.App.Host.linux-x64 │ │ └── 8.0.16 │ ├── Microsoft.NETCore.App.Ref │ │ └── 8.0.16 │ └── NETStandard.Library.Ref │ └── 2.1.0 ├── sdk │ └── 8.0.410 │ ├── AppHostTemplate │ ├── Containers │ ├── cs │ ├── Current │ ├── de │ ├── DotnetTools │ ├── es │ ├── Extensions │ ├── fr │ ├── FSharp │ ├── it │ ├── ja │ ├── ko │ ├── Microsoft │ ├── pl │ ├── pt-BR │ ├── ref │ ├── Roslyn │ ├── ru │ ├── runtimes │ ├── SdkResolvers │ ├── Sdks │ ├── TestHostNetFramework │ ├── tr │ ├── trustedroots │ ├── zh-Hans │ └── zh-Hant ├── sdk-manifests │ └── 8.0.100 │ ├── microsoft.net.sdk.android │ ├── microsoft.net.sdk.aspire │ ├── microsoft.net.sdk.ios │ ├── microsoft.net.sdk.maccatalyst │ ├── microsoft.net.sdk.macos │ ├── microsoft.net.sdk.maui │ ├── microsoft.net.sdk.tvos │ ├── microsoft.net.workload.emscripten.current │ ├── microsoft.net.workload.emscripten.net6 │ ├── microsoft.net.workload.emscripten.net7 │ ├── microsoft.net.workload.mono.toolchain.current │ ├── microsoft.net.workload.mono.toolchain.net6 │ ├── microsoft.net.workload.mono.toolchain.net7 │ └── workloadsets ├── shared │ ├── Microsoft.AspNetCore.App │ │ └── 8.0.16 │ └── Microsoft.NETCore.App │ └── 8.0.16 └── templates └── 8.0.16
Note the wrongly named folder "8.0.410" inside.
forgive my ocd but
.NET 8.0.17 & .NET 9.06 Breaking Change
should be
.NET 8.0.17 & .NET 9.0.6 Breaking Change
forgive my ocd but
.NET 8.0.17 & .NET 9.06 Breaking Change
should be
.NET 8.0.17 & .NET 9.0.6 Breaking Change
good catch @SimonCropp. I fixed it above.
Hi!
It appears that the breaking change actually broke one of our services.
I had a hard time finding information about the existence of a breaking change, since:
- the download page doesn't mention any breaking changes: https://dotnet.microsoft.com/en-us/download/dotnet/9.0,
- nor does the release notes linked from the download page: https://github.com/dotnet/core/blob/main/release-notes/9.0/9.0.6/9.0.6.md,
- nor does this blog post (linked from the release notes under Notable changes): https://devblogs.microsoft.com/dotnet/dotnet-and-dotnet-framework-june-2025-servicing-updates/
The breaking change is listed under a "Known issues" heading in the current Github issue (which is referred to as a "feedback issue"), which is where I first found it.
Now that I know what to look for, I see that it's mentioned in the .NET 9 Known issues document as well.
My feedback:
- The download page ought to mention that a release contains breaking changes.
- Maybe this is a highly personal way of looking at things, but I wouldn't categorize a breaking change as a "known issue". I think it deserves its own category.
- I think a breaking change warrants more than a patch release - this page only mentions breaking changes under a MAJOR version change.
It seems we're running into an issue that started with this version of the runtime. With previous versions, we would generate a build (self-contained) for our Windows Forms application using an Azure DevOps pipeline, put it somewhere on a network share and run it directly from there.
After the agent was updated to SDK 9.0.301, the build suddenly won't run from the network share anymore. It just doesn't show anything and the process briefly shows up in Process Explorer before vanishing again. After some debugging, we saw that the process exits with exit code 0x80008083. If we copy the build to the local machine, it runs just fine. After removing SDK 9.0.301 from the build agent and pinning 9.0.300 in the pipeline, everything started working again.
EDIT: There already seems to be an issue for this: #116521
Hello, Breaking Change: UseForwardedHeaders middleware now always checks ForwardedHeadersOptions.KnownNetworks and ForwardedHeadersOptions.KnownProxies
Please can you provide the feedback if this is fixed in the release .NET 8.0.18 last month and release .NET 8.0.19 this month.
Hello, Breaking Change: UseForwardedHeaders middleware now always checks ForwardedHeadersOptions.KnownNetworks and ForwardedHeadersOptions.KnownProxies
Please can you provide the feedback if this is fixed in the release .NET 8.0.18 last month and release .NET 8.0.19 this month.
Hello @mousamichavanGit , Yes, the fix for this issue has been included in the latest .NET release for 8.0 and 9.0 runtimes via 8.0 PR & 9.0 PR.
Please ensure to update your current .NET versions to the latest 8.0 or 9.0 version to obtain latest fixes delivered.
Thank you!