.NET 8 e 9: fine supporto il 10 novembre, cosa aggiornare

.NET 8 e .NET 9 raggiungono la fine del supporto Microsoft il 10 novembre 2026. Se sul PC, su un server o dentro un’app sono ancora presenti queste versioni, la priorità è individuare quali programmi le usano e pianificare il passaggio a una versione supportata. Installare soltanto un runtime più recente non equivale ad aggiornare automaticamente tutte le applicazioni.

La scadenza non è un interruttore che spegne i programmi: riguarda la fine delle correzioni e dell’assistenza prevista dal ciclo di vita. Un’app che continua ad aprirsi può quindi essere rimasta su una base software non più supportata.

Quali versioni terminano il supporto il 10 novembre

La policy ufficiale Microsoft per .NET indica il 10 novembre 2026 sia per .NET 8 LTS sia per .NET 9 STS. La stessa tabella colloca la fine del supporto di .NET 10 LTS al 14 novembre 2028. Per chi cerca una destinazione di migrazione già stabile, .NET 10 è dunque una versione da valutare con il fornitore o il team che mantiene l’applicazione.

Questa scadenza è distinta da quella di Windows. Nella stessa giornata termina anche il supporto delle edizioni interessate di Windows 11 23H2: aggiornare il sistema operativo non dimostra, da solo, di avere eliminato ogni dipendenza da .NET 8 o 9.

Come controllare i runtime installati

Apri un terminale ed esegui questo comando di sola lettura, indicato nella documentazione Microsoft per rilevare le versioni installate:

dotnet --list-runtimes

Cerca righe con versione 8.0.x o 9.0.x. Possono comparire nomi come Microsoft.NETCore.App, Microsoft.AspNetCore.App e Microsoft.WindowsDesktop.App. Il numero finale della patch non cambia la famiglia di appartenenza: una versione 8.0 aggiornata all’ultima patch resta .NET 8.

Chi sviluppa software può controllare anche gli SDK:

dotnet --list-sdks

Per informazioni aggiuntive sull’ambiente è disponibile dotnet --info. Se il comando non viene riconosciuto, non concludere subito che nessuna app usi .NET: il percorso potrebbe non essere configurato nel PATH e alcune applicazioni includono un proprio runtime. L’elenco è un punto di partenza per l’inventario, non una certificazione completa del PC.

Perché installare .NET 10 può non bastare

Le applicazioni framework-dependent usano un runtime installato nell’ambiente. La scelta della versione segue regole di compatibilità: normalmente un’app passa alle patch ammesse della propria famiglia, non automaticamente a qualunque nuova versione principale. La presenza di .NET 10, quindi, non prova che un programma destinato a .NET 8 abbia smesso di usarlo.

Le applicazioni self-contained, invece, vengono distribuite con il runtime necessario. In quel caso aggiornare il runtime condiviso del computer non aggiorna quello incluso nel pacchetto. Serve una nuova distribuzione dell’app, preparata dal produttore o da chi ne gestisce il codice.

Cosa fare se usi un programma, e cosa fare se lo gestisci

• Se sei un utente: installa gli aggiornamenti ufficiali del programma e chiedi al produttore se la versione corrente dipende ancora da .NET 8 o 9. Non disinstallare runtime alla cieca: potresti impedire l’avvio di software ancora necessario.
• Se gestisci un PC aziendale: consegna all’amministratore l’inventario dei runtime e i nomi delle applicazioni coinvolte. La correzione va coordinata con i tempi di distribuzione e con le policy dell’organizzazione.
• Se mantieni il software: verifica framework di destinazione, dipendenze, immagini container e modalità di distribuzione; prova la migrazione in un ambiente separato, poi distribuisci e verifica il nuovo pacchetto.

Prima di rimuovere le vecchie versioni, controlla avvio, funzioni importanti e integrazioni dell’app aggiornata. Il risultato da ottenere non è semplicemente una lista di runtime più corta: è non avere più applicazioni operative che dipendano da una versione fuori supporto.

Non confondere .NET con .NET Framework

.NET Framework 3.5 e 4.x sono una linea diversa, con proprie regole di supporto. La scadenza di .NET 8 e 9 non significa che occorra disattivare indiscriminatamente le funzionalità .NET Framework di Windows. Se il problema è un errore durante l’abilitazione di un componente, come 0x800f081f durante DISM o .NET Framework 3.5, la diagnosi è diversa dalla migrazione descritta qui.