.NET 8 och 9 slutar stödjas den 10 november

Den 10 november 2026 slutar Microsoft stödja både .NET 8 och .NET 9. Applikationerna slutar inte fungera den dagen, men Microsoft ger efter det inga fler rättningar, uppdateringar eller teknisk support för dem. En sårbarhet som upptäcks efter datumet får alltså ingen patch från Microsoft.

Samma datum gäller ASP.NET Core och Entity Framework Core, som följer samma livscykel. .NET Framework har en egen livscykel och berörs inte.

Varför samma dag?

.NET 8 är en LTS-version med tre års support. .NET 9 är en STS-version, som tidigare hade 18 månaders support och därför skulle ha upphört i maj 2026. I september 2025 förlängde Microsoft STS till 24 månader, vilket flyttade .NET 9 till samma datum som .NET 8.

.NET 10 eller .NET 11?

Vår rekommendation är att gå till .NET 10 nu. Den har funnits i ett år, har fått löpande patchar och stöds till november 2028.

.NET 11 är när detta skrivs fortfarande en förhandsversion. Med den nuvarande modellen om två års STS-support bör den också stödjas till ungefär november 2028, så supporttiden är inte längre det som skiljer dem åt. Skillnaden är att .NET 10 är färdigt i dag. Vill ni ha det som är nytt i .NET 11 är det enklare att ta det steget från .NET 10 när versionen är släppt och era beroenden har hunnit stödja den.

Börja med att ta reda på vad ni kör

Det är sällan bara TargetFramework som behöver ändras. Gå igenom:

• Projektfiler: TargetFramework och TargetFrameworks i alla .csproj, och eventuella gemensamma värden i Directory.Build.props.
• SDK-låsning: global.json, om den finns.
• Containrar: basavbilder i varje Dockerfile.
• Pipelines: .NET-versioner i bygg- och deployflöden.
• Driftmiljö: runtime på servrar och i molntjänster. dotnet --list-runtimes visar vad som finns installerat på en maskin.
• Bortglömda tjänster: bakgrundsjobb och interna verktyg som sällan byggs om är lätta att missa.

Kontrollera också era paket innan ni byter version:

dotnet list package --outdated
dotnet list package --vulnerable --include-transitive

Paket från tredje part är ofta det som avgör hur stort arbetet blir. Ett bibliotek som riktar sig mot net8.0 kan normalt användas från en .NET 10-applikation, men den som underhåller paketet avgör hur länge det uppdateras.

Ändringar som är värda att titta extra på

Microsoft delar in ändringarna i tre typer: binärt inkompatibla, källkodsinkompatibla och beteendeförändringar. Den sista typen är svårast att upptäcka, eftersom koden fortfarande bygger. Exemplen nedan är ett urval, och Microsofts lista är själv inte komplett. Kommer ni från .NET 8 behöver ni också läsa ändringarna för .NET 9.

• Containrar: standardtaggarna för .NET 10 pekar på Ubuntu i stället för Debian, och Microsoft släpper inga Debian-avbilder för .NET 10. Enligt Microsoft påverkas de flesta inte, men testa applikationen på de nya avbilderna och kontrollera steg i er Dockerfile som förutsätter Debian.
• Restore och NuGet: för projekt som riktar sig mot .NET 10 varnar dotnet restore nu även för kända sårbarheter i transitiva paket. Behandlar ni varningar som fel kan det stoppa bygget. En PackageReference utan version ger också ett fel, utom med Central Package Management.
• Bakgrundstjänster: BackgroundService kör nu hela ExecuteAsync på en bakgrundstråd. Tidigare blockerade delen före första await andra tjänster från att starta. Kod som är beroende av den ordningen behöver flyttas, till exempel till StartAsync.
• Konfiguration: null i appsettings.json blev tidigare en tom sträng men binds nu som null. Binds null till exempelvis en int blir värdet 0, där det tidigare gav ett undantag. Ett konfigurationsfel som förut stoppade uppstarten kan alltså passera obemärkt.
• Spårning: standardpropagatorn följer nu W3C och skickar baggage i baggage-headern i stället för Correlation-Context. Kontrollera detta om andra system läser den gamla headern.
• Entity Framework Core 10: Contains på samlingar översätts nu till flera parametrar som standard, och parameternamnen i genererad SQL har ändrats. Det kan påverka prestanda i enskilda frågor, tester som jämför SQL-text och hur frågeplaner cachas direkt efter driftsättning. Med UseAzureSql kan uppgraderingen dessutom generera en migrering som ändrar JSON-kolumner från nvarchar(max) till json.

Ett rimligt arbetssätt

1. Inventera tjänsterna och prioritera det som är exponerat mot internet eller hanterar känslig information.
2. Uppdatera paketen där det går, så att versionsbytet blir en isolerad ändring.
3. Byt till net10.0, kör testerna och läs igenom ändringslistorna för de områden ni använder.
4. Driftsätt först i en testmiljö och jämför loggar, svarstider och databasfrågor med nuläget.
5. Se till att beroendeuppdateringar och framtida patchar kommer med i det ordinarie arbetet, så att nästa versionsbyte blir mindre.

Microsoft har markerat .NET Upgrade Assistant som föråldrad och hänvisar i stället till GitHub Copilot modernization-agenten i Visual Studio. Den kan föreslå en plan och göra vanliga ändringar, men resultatet behöver granskas och testas som all annan kod. Innan en sådan agent får tillgång till kodbasen är det värt att gå igenom vad den får läsa och ändra.

Hinner ni inte före den 10 november?

Applikationerna fortsätter att köras, så datumet är inte en anledning att stressa fram en riskfylld produktionssättning. Det som ändras är att risken växer med tiden, eftersom nya sårbarheter inte längre rättas. Ta därför ett tydligt beslut: vilka tjänster som flyttas först, när det ska vara klart och vem som ansvarar för att följa upp under tiden. Äldre applikationer kan också behöva vägas mot ett större beslut om modernisering eller ersättning.

Källor

• .NET support policy (Microsoft)
• Microsoft .NET and .NET Core lifecycle (Microsoft Learn)
• .NET STS releases supported for 24 months (.NET Blog)
• Breaking changes in .NET 10 (Microsoft Learn)
• Breaking changes in .NET 9 (Microsoft Learn)
• Breaking changes in ASP.NET Core 10 (Microsoft Learn)
• Breaking changes in EF Core 10 (Microsoft Learn)
• .NET Upgrade Assistant overview (Microsoft Learn)