.NET 8 and .NET 9 end of support: what actually breaks

The build stops before the code does

• NU1015: a PackageReference with no version is now an error. It was the NU1604 warning before, and restore quietly picked the lowest available version, which was almost never what anyone wanted. Specify versions; the escape hatch is <SdkAnalysisLevel>9.0.300</SdkAnalysisLevel>, which reverts every behavior gated on that switch and should be temporary.
• HTTP feeds fail in more places. Non-HTTPS package sources have been error NU1302 since the .NET 9 SDK. .NET 10 widens it: http:// audit sources now raise NU1302 as well, and HTTP warnings are promoted to errors in dotnet package list, dotnet package search, and package push and delete. Internal feeds on plain HTTP are common enough that this catches a lot of corporate builds. Move the feed to HTTPS, or set allowInsecureConnections to true on the source in nuget.config while you do.
• NU1510 is a warning raised when a project targeting net10.0 or later has a direct PackageReference that overlaps a library the framework already provides, and NuGet prunes it.
• dotnet restore audits transitive packages. NuGetAuditMode now defaults to all rather than direct for projects targeting .NET 10 or later, so a vulnerability three levels down in a dependency you have never heard of can fail a build that passed yesterday. <NuGetAuditMode>direct</NuGetAuditMode> puts it back.

None of this is difficult. All of it is unbudgeted, and it lands in CI rather than on a developer's machine.

Serialization, which fails quietly

• The in-box BinaryFormatter is gone as of .NET 9. The APIs remain, but the implementation always throws PlatformNotSupportedException, and setting EnableUnsafeBinaryFormatterSerialization is no longer sufficient on its own. Anything that persisted objects with it (legacy session state, a distributed cache, an on-disk queue, a column full of serialized blobs) fails on first use. The only way back is the unsupported System.Runtime.Serialization.Formatters package, and treating that as a destination rather than a bridge is how this becomes next year's problem.
• System.Text.Json now validates property name conflicts. A type with a property named $type, $id, $ref or a configured type discriminator name now throws InvalidOperationException at serialization time rather than emitting invalid JSON with duplicate keys. Rename the property, or mark it [JsonIgnore].
• XmlSerializer no longer ignores properties marked [Obsolete]. Properties deliberately hidden from the wire format come back, so if you have integration partners consuming that XML the contract changes underneath you. [Obsolete(IsError = true)] now throws during serializer creation, and AppContext.SetSwitch("Switch.System.Xml.IgnoreObsoleteMembers", true) restores the old behavior.

These compile cleanly and fail with production data, which is what makes them the expensive ones.

Data access

• SQL parameter names are simplified, so @__city_0 becomes @city. Snapshot tests, query interceptors and anything parsing parameter names will need updating, and cached plans recompile on first run.
• Application Name is injected into the connection string, which can split connection pooling if other data access in the same process uses a different value, and can escalate a TransactionScope to a distributed transaction. Set Application Name explicitly to prevent it.
• Parameterized collections now use multiple parameters by default, which changes query plans. EF.Constant(), EF.Parameter(), EF.MultipleParameters() and the global UseParameterizedCollectionMode give you the old shape back where a plan regression matters.
• On Azure SQL and at compatibility level 170 or higher, the native json type becomes the default for JSON columns that were nvarchar(max). Pin it with HasColumnType("nvarchar(max)") or UseCompatibilityLevel(160) if you are not ready, and note that SQL Server cannot run DISTINCT over JSON arrays, so some queries fail outright after the switch.
• EF tools now require --framework on multi-targeted projects, which breaks migration scripts in CI.

HTTP behavior

• HttpClientFactory uses SocketsHttpHandler as its primary handler as of .NET 9. Proxy resolution, certificate handling and connection lifetime behave differently, which is exactly the class of change that passes every test and then behaves oddly behind a corporate proxy. Code that casts the primary handler to HttpClientHandler now throws InvalidCastException.
• Header values and URI query strings are redacted in HttpClient logging by default. Nothing breaks, but the logs you have been debugging with go quiet at the least convenient moment.
• MailAddress rejects consecutive dots, so addresses that used to validate now do not.
• HTTP/3 is disabled by default when PublishTrimmed or PublishAot is set. Re-enable it with <Http3Support>true</Http3Support>.

Where it runs

• Default container tags are Ubuntu 24.04, and Debian images are not shipped for .NET 10 at all. If your Dockerfile installs packages, assumes paths, or depends on Debian-specific behavior, it needs revisiting. Microsoft's reasoning is support alignment: the Ubuntu base outlives the .NET release, while Debian's does not.
• Non-root and port 8080. The app user (UID 1654) and ASPNETCORE_HTTP_PORTS defaulting to 8080 both arrived in .NET 8, and anyone coming from .NET Framework or an older container setup meets them now. The user is opt-in, so images still run as root unless the Dockerfile adds USER app; the port default is not. Port mappings, Kubernetes manifests, health probes and WEBSITES_PORT on Azure App Service all have to agree.

Desktop and Blazor

• WPF: empty ColumnDefinitions and RowDefinitions elements now fail the XAML compile with MC3063, with no opt-out. A markup file that has been fine for a decade breaks the build.
• Windows Forms: .NET 9 added security analyzers, of which WFO1000 is an error by default and breaks builds of custom controls that do not declare serialization intent. .NET 10 adds obsoletions WFDEV004, WFDEV005 and WFDEV006, which stay warnings unless you treat warnings as errors.
• Blazor WebAssembly: blazor.boot.json is now inlined into dotnet.js. Any deployment that referenced it directly for integrity checks, CDN rules or assembly renaming needs another approach. BlazorCacheBootResources is gone, and the Blazor-Environment header is replaced by WasmApplicationEnvironmentName.
• ASP.NET Core: MapStaticAssets() arrived in .NET 9 and fingerprints and pre-compresses app-owned assets at build time, changing cache behavior and asset URLs. It complements UseStaticFiles() rather than replacing it: default documents, files outside the web root, directory browsing and custom response headers still need the middleware, and dropping it returns 404 for /.