Windows 11 26H2, segnalazioni di .NET Framework disabilitato dopo l'aggiornamento

L’aggiornamento a Windows 11 26H2 sta creando problemi ad alcuni amministratori IT: dopo il passaggio alla nuova versione del sistema operativo, applicazioni che prima funzionavano regolarmente non riescono più ad avviarsi perché .NET Framework 3.5 risulta disabilitato o non disponibile. Il componente, indispensabile per numerosi programmi sviluppati con tecnologie Microsoft meno recenti, sembra perdere il proprio stato di attivazione durante alcune procedure di aggiornamento all’ultimo feature update di Windows 11.

La problematica interessa soprattutto le imprese che utilizzano ancora software gestionali, applicazioni industriali e strumenti di manutenzione legati alle vecchie librerie Microsoft.

Rilasciato nel novembre 2007, .NET Framework 3.5 ha ricevuto il Service Pack 1 nel 2008 e continua a garantire la compatibilità con applicazioni progettate per le versioni 2.0 e 3.0. Nonostante l’età, Microsoft ne assicura il supporto fino al 9 gennaio 2029.

Windows 11 26H2 disabilita .NET Framework 3.5: le segnalazioni degli amministratori

Molti amministratori hanno in questi giorni segnalato lo stesso comportamento: dopo l’aggiornamento a Windows 11 26H2, i programmi dipendenti da .NET Framework 3.5 hanno cominciato a richiederne l’installazione, nonostante il componente fosse già presente e funzionante prima dell’operazione.

Microsoft spiega nella documentazione ufficiale di Windows 11 26H2 che le versioni 24H2, 25H2 e 26H2 condividono la stessa base di manutenzione. Sui computer idonei, il passaggio a 26H2 può quindi avvenire attraverso un pacchetto di abilitazione (eKB o enablement package) di dimensioni contenute, senza richiedere una reinstallazione completa del sistema operativo.

Il pacchetto di abilitazione (abbiamo visto come usarlo per aggiornare a Windows 11 26H2 anche sui PC non supportati, in 2 minuti) attiva funzionalità già distribuite agli utenti di Windows 11 attraverso gli aggiornamenti cumulativi, mentre un aggiornamento completo comporta una procedura più articolata, durante la quale Windows Setup deve trasferire configurazioni, applicazioni, driver e componenti facoltativi dalla precedente installazione.

L’aggiornamento mediante enablement package non sembra disattivare .NET Framework 3.5, mentre alcune installazioni effettuate utilizzando un’immagine ISO ne ha comportato la perdita.

Per 26H2 non esistono ancora elementi sufficienti per attribuire con certezza la disabilitazione del .NET Framework 3.5 a uno specifico aggiornamento cumulativo, a un difetto del sistema operativo o a un prodotto di distribuzione di terze parti. Prematuro sostenere che Windows 11 26H2 rimuova .NET Framework 3.5 da tutti i computer aggiornati.

Come verificare se .NET Framework 3.5 è ancora attivo dopo l’aggiornamento

Chi ha appena installato Windows 11 26H2 può iniziare da una verifica piuttosto semplice. Premendo Windows+R e digitando optionalfeatures, è possibile aprire la finestra delle funzionalità facoltative di Windows. Nei sistemi che supportano ancora NetFx3 come componente integrato, la voce da controllare è “.NET Framework 3.5 (include .NET 2.0 e 3.0)“.

Per una verifica più precisa, soprattutto nelle reti gestite centralmente, è preferibile utilizzare il comando DISM. Da un terminale aperto con privilegi amministrativi si può eseguire quanto segue, osservando quanto riportato a destra dell’indicazione Stato:

DISM /Online /Get-FeatureInfo /FeatureName:NetFx3.

Lo stesso controllo può essere effettuato attraverso PowerShell con il comando Get-WindowsOptionalFeature -Online -FeatureName NetFx3. È un metodo particolarmente utile per raccogliere informazioni sulle postazioni aziendali prima e dopo l’aggiornamento.

Attenzione anche a un dettaglio: trovare le directory C:\Windows\Microsoft.NET\Framework e C:\Windows\Microsoft.NET\Framework64 non implica che .NET Framework 3.5 sia operativo. Il computer potrebbe disporre soltanto dei runtime della famiglia .NET Framework 4.x, che non sostituiscono quelli della linea 2.0 e 3.5.

Come ripristinare .NET Framework 3.5 senza reinstallare Windows

Se NetFx3 risulta disponibile ma disabilitato, l’amministratore può riattivarlo attraverso la finestra delle funzionalità di Windows oppure utilizzare il comando DISM /Online /Enable-Feature /FeatureName:NetFx3 /All, eseguito da un terminale con privilegi elevati.

L’opzione /All richiede l’attivazione delle funzionalità padre necessarie: quando il sistema non possiede localmente i file del componente, la procedura può tentare di recuperarli dalle origini configurate per la manutenzione di Windows.

Negli ambienti aziendali isolati da Internet, oppure nei casi in cui Windows Update non possa fornire il materiale necessario, la documentazione Microsoft per DISM descrive anche una modalità di installazione da supporto locale:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs.

Il percorso D:\sources\sxs è soltanto un esempio e deve corrispondere alla posizione reale dei file. L’origine deve inoltre essere compatibile con la versione di Windows installata: Microsoft avverte infatti che utilizzare file appartenenti a release differenti può introdurre uno stato non supportato e compromettere la successiva manutenzione del sistema.

Quali log analizzare per individuare la causa del problema

Il ripristino del framework risolve l’inconveniente ma non chiarisce perché la funzionalità abbia smesso di funzionare. Per chi gestisce numerose macchine, il passaggio successivo consiste nell’esaminare i registri prodotti durante l’aggiornamento.

Il file C:\Windows\Logs\CBS\CBS.log contiene informazioni sulle operazioni del servizio Component-Based Servicing, responsabile della gestione di numerosi componenti Windows. Le registrazioni possono aiutare a individuare modifiche allo stato di NetFx3, errori di manutenzione e problemi relativi ai pacchetti.

Anche C:\Windows\Logs\DISM\dism.log può risultare utile quando l’attivazione o il ripristino sono avvenuti attraverso DISM. Per le operazioni di aggiornamento completo è invece opportuno esaminare i file di Windows Setup, in particolare quelli conservati nelle directory Panther, come C:\Windows\Panther e, quando ancora disponibili, C:\$WINDOWS.~BT\Sources\Panther.

I registri di Windows Update e del prodotto aziendale utilizzato per distribuire le patch permettono di ricostruire la cronologia: quale aggiornamento è stato rilevato, quando è partita l’installazione, quale comando ha effettivamente eseguito il sistema di gestione e se il computer ha effettuato più passaggi di aggiornamento.

Perché il problema riguarda tanti software aziendali

Un framework pubblicato quasi 20 anni fa potrebbe ormai sembra preistorico. Eppure, molte aziende continuano a utilizzare programmi che dipendono da librerie compilate per CLR 2.0, il Common Language Runtime impiegato dalle applicazioni .NET Framework 2.0, 3.0 e 3.5.

CLR è l’ambiente di esecuzione che gestisce il codice .NET, occupandosi tra l’altro della compilazione just-in-time, della memoria e della gestione delle eccezioni: la presenza delle versioni moderne del framework non elimina la necessità di installare .NET Framework 3.5 per alcune specifiche applicazioni.