Verze .NET, LTS vs STS a kdy přejít na novou

V produkci provozuj vydání LTS, pokud nemáš důvod jinak, a upgrade plánuj před koncem podpory, ne po něm. K říjnu 2026 to znamená .NET 10, aktuální vydání s dlouhodobou podporou, podporované do listopadu 2028. .NET 8 (LTS) i .NET 9 (STS) končí s podporou 10. listopadu 2026 - tedy za pár týdnů - takže všechno, co na nich pořád běží, by se mělo přesouvat. .NET 11 má vyjít v listopadu 2026 jako vydání se standardní podporou. Tento článek vysvětluje model podpory, co se doopravdy stane, když verze podporu ztratí, jak přesunout projekt mezi verzemi bez nepříjemných překvapení a jak global.json a nastavení roll-forward ovlivňují, jaké SDK a runtime dostaneš.

Model vydávání: jedna major verze ročně#

Microsoft vydává novou major verzi .NET každý listopad. Sudá vydání jsou LTS (long-term support, dlouhodobá podpora) a lichá jsou STS (standard-term support, standardní podpora).

Okno podpory STS bývalo 18 měsíců. Od .NET 9 ho Microsoft prodloužil na 24 měsíců, proto .NET 9 končí ve stejný den jako .NET 8 místo o půl roku dřív. Vydání STS není beta - je plně podporované, dostává stejné měsíční záplaty a v produkci ho používá spousta týmů, které chtějí novinky o rok dřív. Cenou je, že upgraduješ každý rok místo každých dvou tří let.

Aktuální životní cyklus verzí, na které pravděpodobně narazíš:

Záplaty vycházejí na Patch Tuesday, druhé úterý každého měsíce. Datum konce podpory je poslední den záplat; po něm verze nedostává žádné bezpečnostní opravy. Oficiální stránka zásad podpory .NET od Microsoftu je zdroj, který si ověř, než podle některého data z této tabulky něco naplánuješ.

Co konec podpory skutečně znamená#

V den konce podpory se nic nevypne. Aplikace na .NET 8 se 11. listopadu 2026 spustí úplně stejně jako den předtím. Mění se tohle:

• Žádné další bezpečnostní záplaty. Další zranitelnost v Kestrelu, v zásobníku TLS, v System.Text.Json nebo v samotném runtime zůstane ve tvé verzi otevřená navždy. U webové aplikace dostupné z internetu je to celý argument.
• Obrazy kontejnerů se přestanou aktualizovat. Tagy mcr.microsoft.com/dotnet/aspnet:8.0 půjde dál stáhnout, ale balíčky základního operačního systému pod nimi se už také neobnovují.
• Knihovny jdou dál. Balíčky NuGet v následujícím roce nebo dvou opouštějí staré cíle a verze knihovny, která opravuje chybu, jakou jsi potkal, nemusí tvůj framework podporovat.
• Hostitelé a nástroje jdou dál. Build agenti, instalátory SDK a hostingové image přestanou časem staré runtime nabízet.

Praktické pravidlo: vydání LTS ti dává rok překryvu s dalším LTS. Upgraduj během toho roku, kdy nová verze už má pár prvních záplat a knihovny, které používáš, se dotáhly, ne v posledním měsíci.

Target framework, SDK a runtime: tři různé verze#

Většina zmatků kolem upgradu vzniká tím, že se tyto věci berou jako jedno číslo.

• Target framework - proti čemu se projekt kompiluje, nastavuje se v souboru projektu jako <TargetFramework>net10.0</TargetFramework>. Rozhoduje, která API můžeš volat a jaký runtime aplikace potřebuje.
• SDK - nástrojová sada, která projekt sestavuje: dotnet build, dotnet publish, kompilátory. Verze SDK vypadají jako 10.0.100; číslice stovek je feature band (10.0.1xx, 10.0.2xx) a poslední dvě číslice jsou záplata.
• Runtime - co spouští zkompilovanou aplikaci. Aplikace ASP.NET Core potřebují sdílený runtime ASP.NET Core stejné major verze, číslovaný jako 10.0.0, 10.0.1 a tak dále.

SDK umí sestavit svou vlastní verzi i všechny starší target frameworky, takže SDK .NET 10 bez problému sestaví projekt net8.0. Obráceně to nejde: SDK .NET 8 neumí sestavit net10.0. Runtime spouští aplikace cílící na svou major verzi a s nastavením roll-forward někdy i novější.

$ dotnet --list-sdks8.0.415 [/usr/share/dotnet/sdk]10.0.100 [/usr/share/dotnet/sdk]$ dotnet --list-runtimesMicrosoft.AspNetCore.App 10.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]Microsoft.NETCore.App 10.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Chyba, na kterou lidé narazí, když runtime a cíl nesedí, se nedá splést:

You must install or update .NET to run this application.Framework: 'Microsoft.AspNetCore.App', version '10.0.0' (x64)The following frameworks were found:  8.0.11 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]

Na hostovaném aplikačním serveru je dostupný runtime ten, který poskytuje image serveru, takže než změníš cílovou verzi, zjisti, jaké SDK a runtime obsahuje. Self-contained publikování se tomu úplně vyhne tím, že runtime dodá uvnitř výstupu buildu, za cenu mnohem většího nasazení; tuto výměnu popisuje dotnet publish a volby runtime.

Připnutí SDK pomocí global.json#

Bez global.json používá dotnet nejnovější SDK nainstalované na stroji. Na notebooku to obvykle chceš a na build serveru to občas dělá potíže, protože aktualizace SDK může mezi dvěma buildy stejného commitu změnit varování analyzátorů, výchozí chování nebo formát generovaných souborů.

{  "sdk": {    "version": "10.0.100",    "rollForward": "latestFeature"  }}

version je minimální SDK. rollForward určuje, jak daleko nad ni smí dotnet zajít:

latestFeature je rozumná volba pro většinu repozitářů: buildy zůstanou na SDK .NET 10 a přesto přebírají záplaty i feature bandy. disable zní bezpečně a rozbije build na každém stroji, který má záplatu novější než ty. Pokud žádné nainstalované SDK soubor nesplňuje, chyba uvede verzi, kterou chtěla - nainstaluj to SDK nebo uvolni politiku.

global.json ovlivňuje jen SDK. Nemění target framework a nemění, na jakém runtime aplikace běží.

Roll-forward runtime#

Framework-dependent aplikace cílící na net10.0 běží automaticky na nejvyšší nainstalované záplatě 10.0.x runtime. Takhle se záplatovanému runtime dostanou bezpečnostní opravy k tvé aplikaci bez nového buildu, a proto se nemáš snažit připnout konkrétní záplatu runtime.

Napříč minor a major verzemi řídí chování vlastnost projektu RollForward (nebo proměnná prostředí DOTNET_ROLL_FORWARD):

Major umožní aplikaci net8.0 spustit se na stroji, který má jen runtime .NET 10. Většinou to funguje a není to náhrada za upgrade: běžíš na runtime, proti kterému se aplikace nikdy netestovala, a všechny zásadní změny mezi oběma verzemi se uplatní potichu. Použij to k získání času v nouzi, ne jako politiku.

Upgrade projektu krok za krokem#

Přechod z .NET 8 na .NET 10 je u většiny webových aplikací krátká práce, když se dělá ve správném pořadí:

1. Nainstaluj nové SDK a přidej nebo uprav global.json, aby se repozitář s ním sestavoval.
2. Změň target framework v každém projektu: net8.0 na net10.0. V řešení s mnoha projekty ušetří úpravy každého souboru Directory.Build.props, který nastaví TargetFramework jednou.
3. Aktualizuj balíčky Microsoftu na odpovídající major verzi. Balíčky jako Microsoft.AspNetCore.Authentication.JwtBearer, Microsoft.EntityFrameworkCore.* a Microsoft.Extensions.* mají verze shodné s runtime; aplikace net10.0 by měla používat jejich verze 10.x.
4. Aktualizuj balíčky třetích stran, zejména databázové providery. Npgsql, provider Pomelo pro MySQL a další vydávají jednu verzi na každou major verzi EF Core; než začneš, ověř, že ta, kterou potřebuješ, existuje.
5. Sestav s viditelnými varováními a přečti si je. Nové analyzátory a zastaralá API se objeví nejdřív jako varování.
6. Přečti si seznam zásadních změn pro každou verzi, kterou přeskakuješ. Microsoft ho publikuje pro každé vydání v dokumentaci .NET, seřazený podle oblastí. Přechod z 8 na 10 znamená přečíst seznamy pro 9 i pro 10.
7. Spusť testy, potom spusť aplikaci nad kopií produkčních dat a nasaď na testovací server dřív než do produkce.

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

Druhý příkaz stojí za spuštění v každém projektu bez ohledu na upgrady: vypíše balíčky se známými zranitelnostmi, včetně těch, které se přitáhly nepřímo.

Několik změn z posledních verzí, které lidi opravdu překvapí:

• .NET 8 změnil výchozí port v kontejnerových obrazech ASP.NET Core od Microsoftu z 80 na 8080 a přidal ASPNETCORE_HTTP_PORTS jako jednodušší způsob jeho nastavení. Aplikace, které uvnitř kontejneru spoléhaly na port 80, po aktualizaci základního obrazu přestaly odpovídat.
• .NET 9 odstranil implementaci `BinaryFormatter` - za běhu vyhazuje výjimku. Starý kód pro cache nebo session, který jím serializoval objekty, selže až ve chvíli, kdy se tato cesta kódu vykoná.
• Major verze EF Core sledují runtime. EF Core 10 vyžaduje .NET 10, takže nový EF Core nejde použít bez nového runtime a migrace vygenerované novějším nástrojem EF Core je vhodné před aplikováním zkontrolovat. Migrace EF Core v produkci popisuje, jak je aplikovat bezpečně.

Nasazení upgradu bez sázky celé produkce#

Nejbezpečnější upgrade je ten, který jde za minutu vrátit. Drž upgrade na vlastní větvi a nasaď ji na druhý, malý server dřív, než se dostane k tomu, na který chodí uživatelé. Testovací server, který si při startu stáhne větev s upgradem a míří na kopii produkční databáze, zachytí dvě chyby, které unit testy minou: závislost, která se za běhu chová jinak, a migraci, která je na skutečných datech pomalá nebo zamyká tabulku. Testovací server vedle produkčního popisuje, jak oba držet oddělené, a nasazení aplikace ASP.NET Core z GitHubu popisuje samotné nasazení.

Před přepnutím produkce udělej zálohu databáze a zajisti, že předchozí build je vzdálený jeden commit. Pokud se nová verze chová špatně, vrácení commitu s target frameworkem a nové nasazení je rollback; migrace databáze, která už proběhla, je ta část, kterou tak snadno vrátit nejde, a proto by se změny schématu měly nasazovat samostatně před upgradem runtime nebo po něm, ne současně.

Přechod knihovny net8.0 na multi-targeting je dobrý mezikrok, když na ní závisí víc aplikací: <TargetFrameworks>net8.0;net10.0</TargetFrameworks> (všimni si množného čísla) sestaví obě varianty a každá aplikace si vybere tu odpovídající.

LTS, nebo STS: které provozovat?#

LTS, pokud se aplikace udržuje po dávkách, pokud upgrady potřebují schválení nebo pokud je tým jeden člověk, který má na práci i jiné věci. Tři roky záplat a rok překryvu s dalším LTS odpovídá pomalejšímu rytmu.

STS, pokud nasazuješ průběžně, závislosti aktualizuješ rutinně a chceš novinky - zejména zlepšení výkonu přicházejí každý rok - o dvanáct měsíců dřív. S 24 měsíci podpory už vydání STS není volbou s krátkým doutnákem jako dřív, ale pořád končí ve stejnou dobu jako předchozí LTS nebo dřív, takže se zavazuješ k upgradu každý rok.

Co provozovat nemáš, je verze bez podpory ani preview v produkci. Preview a release candidate se objevují od února každého roku; release candidate mají od Microsoftu licenci go-live, což znamená podporu pro produkční použití, ale aplikace závislá na preview runtime na hostovaném serveru závisí na tom, že ho ten server nabízí.

Verze jazyka C# následují SDK: C# 12 vyšlo s .NET 8, C# 13 s .NET 9, C# 14 s .NET 10. Výchozí LangVersion je ta, která odpovídá tvému target frameworku, a nastavit ji výš, než cíl podporuje, není podporované, i když se to zkompiluje.

.NET Framework je jiný produkt#

Poslední bod, který pro hosting záleží: .NET Framework 4.x není .NET. Je to původní framework jen pro Windows, pořád podporovaný jako součást Windows, pořád na něm běží spousta softwaru, a na Linuxu nefunguje. Aplikaci ASP.NET (ne ASP.NET Core) na .NET Framework 4.8 nelze do linuxového kontejneru nasadit vůbec. Přesun znamená portování na ASP.NET Core na .NET 10, což je u aplikací MVC skutečný migrační projekt, ne změna cílové verze - System.Web v moderním .NET neexistuje.

Knihovny, které musí sloužit oběma světům, cílí na netstandard2.0, které umí použít .NET Framework 4.6.1 a novější i každé moderní .NET. Nové knihovny jen pro moderní .NET by měly cílit přímo na net8.0 nebo novější.

FAQ#

Je .NET 8 pořád bezpečné používat?

Do 10. listopadu 2026 dostává bezpečnostní záplaty, takže dnes je bezpečné. Po tomto datu nedostává nic. Pokud teď běžíš na .NET 8, upgrade na .NET 10 by se měl naplánovat, ne zvažovat.

Mám přeskočit .NET 11 a počkat na .NET 12?

Pokud provozuješ vydání LTS, ano: jdi z 10 na 12, které se očekává v listopadu 2027, v roce, kdy jsou podporované obě. Pokud provozuješ vydání STS, vezmi 11, až vyjde a bude venku první záplata.

Musím aplikaci znovu sestavit při každé měsíční záplatě?

U framework-dependent aplikací ne. Aplikace automaticky přejde na nejnovější nainstalovanou záplatu svého runtime. Self-contained aplikace nesou vlastní runtime, takže na každou záplatu potřebují nový build a nasazení.

Může aplikace .NET 8 běžet na runtime .NET 10?

Jen s RollForward nastaveným na Major nebo LatestMajor, a pak bez jakéhokoli testování proti zásadním změnám novějšího runtime. Správné řešení je změnit cíl na net10.0 a otestovat.

Co dělá global.json, když ho nemám?

Nic, což znamená, že projekt sestaví nejnovější nainstalované SDK. Lokálně je to v pořádku a na build serverech to může způsobit drift. Přidej ho s rollForward nastaveným na latestFeature, aby buildy zůstaly na major verzi, kterou chceš.