Panoramica dell'aggiornamento delle app Windows Forms

Questo articolo consente di comprendere cosa riguarda l'aggiornamento di un'app Windows Forms da .NET Framework a .NET. Windows Forms è supportato su .NET e riceve investimenti attivi, tra cui controlli più recenti, miglioramenti a valori DPI elevati e aggiornamenti dell'accessibilità. Se mantieni un'app Windows Forms esistente e vuoi sfruttare tali miglioramenti o passare a una versione supportata di .NET, questo articolo fa al caso tuo.

L'articolo illustra i motivi per eseguire l'aggiornamento, i percorsi di aggiornamento disponibili e il lavoro di preparazione che rende l'aggiornamento senza problemi. Spiega anche quali tecnologie di .NET Framework non hanno equivalenti in .NET, come colmare le lacune nelle API usando Windows Compatibility Pack e come le modifiche che causano incompatibilità possono influire sull'applicazione.

Per un esempio su come eseguire l'aggiornamento, vedere Aggiornare un'app Windows Forms a .NET con la modernizzazione di GitHub Copilot.

Perché eseguire l'aggiornamento

.NET Framework è un runtime di origine chiusa Windows che non riceve più gli aggiornamenti delle funzionalità. Sebbene continui a ricevere patch di sicurezza per le versioni supportate, non trae vantaggio dal lavoro sulle prestazioni, dai miglioramenti del linguaggio o dagli investimenti attivi che .NET. Se si gestisce un'app Windows in .NET Framework, l'aggiornamento a .NET consente di accedere a una piattaforma più veloce e più in grado di essere sviluppata attivamente all'aperto.

Restare aggiornati sulle versioni di .NET è importante. Ogni versione .NET ha una finestra di supporto definita e le app in esecuzione in una versione non supportata interrompono la ricezione di patch e correzioni di sicurezza. Eseguire l'aggiornamento prima della fine del supporto per rimanere protetti.

.NET offre miglioramenti significativi delle prestazioni per l'avvio, la velocità effettiva e l'utilizzo della memoria in fase di esecuzione. Le app desktop in .NET traggono vantaggio anche dall'investimento continuo delle funzionalità:

  • Controlli più recenti, miglioramenti dell'accessibilità e miglioramenti a valori DPI elevati.
  • Migliore integrazione con Windows. Alcune funzionalità, ad esempio la modalità scura in Windows 11, sono disponibili solo in .NET.
  • Funzionalità del linguaggio C# e Visual Basic più recenti e strumenti migliorati.
  • Un ricco ecosistema di pacchetti NuGet destinati a .NET.

.NET rilascia una nuova versione principale ogni anno, alternando tra le versioni LTS (Long-Term Support) e stS (Standard-Term Support):

  • Le versioni LTS sono supportate per tre anni e sono in genere la scelta migliore per le app di produzione che preferiscono la stabilità.
  • Le versioni stS sono supportate per 24 mesi e sono utili quando si vogliono adottare le nuove funzionalità prima.

Pianificare la cadenza dell'aggiornamento in base a queste date in modo che l'app sia sempre in una versione supportata. Per le versioni correnti supportate e le date di fine del supporto, vedere .NET versioni, patch e supporto.

Percorsi di aggiornamento

La maggior parte degli aggiornamenti rientra in una delle due categorie. Identificare il percorso applicabile all'app, quindi usare le indicazioni e gli strumenti in questo articolo per completare il lavoro.

  • Da .NET Framework a .NET: modifica più significativa.

    Il formato del file di progetto, alcune API e alcune tecnologie sono diverse. Esaminare i prerequisiti, valutare le dipendenze e pianificare le lacune dell'API prima di iniziare.

    Dopo che l'app è stata compilata ed eseguita in .NET, è possibile adottare facoltativamente schemi più recenti, ad esempio la configurazione appsettings.json, l'iniezione delle dipendenze o i servizi cloud. L'adozione di questi modelli è separata dalla modernizzazione alla .NET e non è necessaria per completare l'aggiornamento. Per idee e indicazioni, vedere Modernizzare dopo l'aggiornamento a .NET da .NET Framework.

  • Da una versione .NET precedente a quella più recente: un aggiornamento con ambito più piccolo.

    Le attività principali sono l'aggiornamento dell'identificatore del framework di destinazione, l'esame delle modifiche che causano un'interruzione per le versioni che si stanno superando e l'aggiornamento delle dipendenze NuGet.

Eseguire l'aggiornamento da .NET Framework a .NET

L'aggiornamento da .NET Framework a .NET è il percorso di aggiornamento più significativo e l'obiettivo principale di questa sezione.

Importante

Anche se .NET è una tecnologia multipiattaforma, le app desktop Windows per .NET rimangono solo Windows.

Una modifica è il formato del file di progetto. .NET usa il formato di progetto in stile SDK, che è più conciso del formato legacy. È possibile convertire il file di progetto in stile SDK mentre è ancora destinato a .NET Framework, riducendo così l'ambito della modifica durante la porta effettiva e offre una baseline migliore da cui lavorare.

Non tutte le API di .NET Framework sono disponibili in .NET. Alcune API esistono sulla superficie, ma generano un'eccezione PlatformNotSupportedException in fase di esecuzione. Il pacchetto di compatibilità Windows (Microsoft.Windows.Compatibility pacchetto NuGet) riempie molte di queste lacune fornendo l'accesso alle API specifiche di Windows, ad esempio il Registro di sistema Windows, Windows registro eventi e altro ancora. Per informazioni dettagliate, vedere Usare il pacchetto di compatibilità Windows per convertire il codice per .NET.

Alcune tecnologie di .NET Framework non hanno equivalenti in .NET e richiedono approcci alternativi, ad esempio domini applicazione, sicurezza dall'accesso al codice e Windows Workflow Foundation. Per altre informazioni, vedere la sezione Tecnologie .NET Framework non disponibili.

Controllare le dipendenze di terze parti. I controlli e le librerie destinati solo a .NET Framework potrebbero non funzionare in .NET. Preferisci i pacchetti NuGet destinati a .NET Standard 2.0 o direttamente a .NET. Per i pacchetti che non sono stati trasferiti, cercare alternative della community o verificare se il pacchetto di compatibilità Windows copre le API necessarie.

Eseguire l'aggiornamento tra versioni di .NET

Il passaggio da una versione .NET a un'altra, ad esempio da .NET 9 a .NET 10, è in genere uno sforzo inferiore rispetto alla modernizzazione da .NET Framework. L'attività principale consiste nell'aggiornare la proprietà <TargetFramework> nel file di progetto con il nuovo identificatore del framework di destinazione. Ad esempio, passando net9.0-windows a net10.0-windows.

Prima di aggiornare la destinazione, esaminare la documentazione delle modifiche di rilievo per ogni versione che si sta attraversando. Le modifiche che introducono incompatibilità possono essere comportamentali, influire sulla compatibilità binaria o del codice sorgente oppure modificare il comportamento in fase di progettazione. Anche differenze minime tra versioni secondarie possono introdurre modifiche che possono influire sulla tua app. Rivedere Modifiche di rilievo in .NET e filtrare l'intervallo di versioni in cui si esegue l'aggiornamento.

Dopo aver aggiornato il framework di destinazione, aggiorna le dipendenze NuGet. I pacchetti destinati alle versioni precedenti .NET potrebbero avere versioni più recenti che sfruttano il runtime corrente. Verificare la disponibilità di aggiornamenti e preferire i pacchetti destinati alla versione in cui si sta passando. Alcuni pacchetti potrebbero anche avere API deprecate o un comportamento modificato nelle versioni più recenti, quindi esaminare le note sulla versione durante l'aggiornamento.

Modernizzazione di GitHub app Copilot

L'agente di modernizzazione GitHub Copilot è lo strumento consigliato per l'aggiornamento di app Windows Forms e macchine virtuali Windows. Si tratta di un'esperienza end-to-end basata su intelligenza artificiale integrata in GitHub Copilot che gestisce l'intero processo di aggiornamento.

L'agente segue un flusso di lavoro a tre fasi:

  • Valutazione. Copilot esamina la struttura, le dipendenze e i modelli di codice del progetto. Identifica le modifiche di rilievo, i problemi di compatibilità delle API, i modelli deprecati e l'ambito generale dell'aggiornamento. Presenta quindi decisioni di strategia, ad esempio l'ordine di aggiornamento e la gestione della compatibilità, per poter esaminare prima di procedere.

  • Pianificazione. Copilot converte la valutazione e le scelte confermate in un piano di aggiornamento dettagliato, documentando strategie di aggiornamento, approcci di refactoring, percorsi di dipendenza e mitigazioni dei rischi.

  • Esecuzione. Copilot suddivide il piano in attività sequenziali con criteri di convalida, applica correzioni del codice e esegue il commit incrementale delle modifiche. Se si verifica un problema che non è in grado di risolvere automaticamente, chiede aiuto e apprende dalla correzione.

Tutto lo stato di aggiornamento viene archiviato nel .github/upgrades/ repository, quindi è possibile sospendere e riprendere tra le sessioni o passare da un ambiente di sviluppo all'altro senza perdere lo stato di avanzamento.

L'agente supporta questi percorsi di aggiornamento:

  • .NET Framework (qualsiasi versione) per .NET 8 o versione successiva
  • .NET Core 1.x–3.x per .NET 8 o versione successiva
  • da .NET 5-7 a .NET 8 o versioni successive
  • Migrazione ai servizi di Azure

È disponibile in Visual Studio 2026, Visual Studio 2022 17.14.16+, Visual Studio Code e GitHub CLI. Per avviare un aggiornamento in Visual Studio, fare clic con il pulsante destro del mouse sulla soluzione o sul progetto in Esplora soluzioni e selezionare Modernize (Modernizzare) oppure aprire la finestra di gitHub Copilot Chat e digitare @Modernize. In Visual Studio Code aprire il pannello Copilot Chat GitHub e digitare @modernize-dotnet.

Per informazioni dettagliate sulla configurazione e sull'utilizzo, vedere Che cos'è la modernizzazione con GitHub Copilot?.

Tecnologie .NET Framework non disponibili

Diverse tecnologie .NET Framework non hanno equivalenti in .NET e richiedono approcci alternativi prima che l'app possa essere eseguita nel nuovo runtime. Identificare se l'app dipende da una di queste tecnologie in anticipo, perché rappresentano la categoria più dirompente del lavoro di migrazione. Per informazioni di riferimento complete, vedere tecnologie .NET Framework non disponibili in .NET.

  • Domini di applicazione

    AppDomain non è supportata. Usare AssemblyLoadContext per il caricamento di assembly dinamico e usare processi o contenitori separati per l'isolamento. Alcuni AppDomain membri dell'API sono presenti ma generano un'eccezione PlatformNotSupportedException in fase di esecuzione.

  • Comunicazione remota

    .NET Remoting non è supportato. Usare System.IO.Pipes o MemoryMappedFile per IPC locale o gRPC e ASP.NET Core per la comunicazione tra computer. Anche le chiamate a BeginInvoke() e EndInvoke() sugli oggetti delegate generano PlatformNotSupportedException.

  • Sicurezza dall'accesso al codice

    Cas non è supportato e non è più un limite di sicurezza. Usare invece limiti di sicurezza a livello di sistema operativo, ad esempio virtualizzazione, contenitori o account utente.

  • Trasparenza della sicurezza

    La trasparenza della sicurezza, che separa il codice in modalità sandbox dal codice critico per la sicurezza, non è più supportato come limite di sicurezza. Come cas, questa funzionalità si basava sull'imposizione di runtime che .NET non fornisce. Usare invece meccanismi di isolamento a livello di sistema operativo.

  • Windows Workflow Foundation (WF)

    WF non è supportato in .NET. Se l'app ospita o usa flussi di lavoro, prendere in considerazione CoreWF, una porta open source del runtime di Windows Workflow Foundation destinata a .NET.

  • System.EnterpriseServices (COM+)

    System.EnterpriseServices non è supportata. Le app che usano servizi COM+ come il pool di oggetti, le transazioni o la sicurezza basata sui ruoli tramite System.EnterpriseServices devono essere riprogettati per usare alternative. Per le transazioni distribuite, prendere in considerazione System.Transactions. Per gli scenari di hosting dei servizi, prendere in considerazione ASP.NET Core o i servizi di lavoro.

Si noti che alcune API in queste aree sono presenti in .NET, ma generano PlatformNotSupportedException in fase di esecuzione anziché causare un errore in fase di compilazione. Testa l'app con .NET nelle prime fasi della migrazione per individuare questi problemi prima di investire in un porting completo.

Prima di iniziare l'aggiornamento da .NET Framework

Prima di iniziare a convertire l'app in .NET, completare un set di passaggi preliminari mentre il progetto è ancora destinato a .NET Framework. Questa attività di base riduce prima di tutto l'ambito della modifica durante l'aggiornamento effettivo e offre una linea di base più pulita e convalidata da cui iniziare. Per informazioni di riferimento complete, vedere Prerequisiti per la conversione del codice da .NET Framework.

  • Aggiornare gli strumenti.

    Assicurarsi di eseguire una versione di Visual Studio che supporti la versione di .NET di destinazione. Le versioni più recenti dell'SDK includono il supporto della migrazione migliorato, gli analizzatori migliori e i modelli di progetto aggiornati. Per la relazione tra le versioni di .NET SDK, MSBuild e Visual Studio, vedere Relazione di controllo delle versioni tra .NET SDK, MSBuild e Visual Studio.

  • Usare .NET Framework 4.7.2 o versioni successive.

    Reindirizza il progetto a .NET Framework 4.7.2 o versione successiva prima della migrazione. Questa versione offre la superficie di compatibilità API più ampia con .NET Standard 2.0, riducendo il numero di lacune dell'API che si riscontrano durante l'aggiornamento.

    In Visual Studio, fare clic con il pulsante destro del mouse sul progetto, selezionare Proprietà e quindi impostare l'elenco a discesa Framework di destinazione su .NET Framework 4.7.2. Ricompilare e risolvere eventuali problemi prima di procedere.

  • Converti in formato PackageReference.

    Se il progetto usa un packages.config file per gestire i riferimenti NuGet, eseguire la migrazione al PackageReference formato. PackageReference è l'approccio moderno e si integra direttamente nel formato di progetto in stile SDK che verrà adottato nel passaggio successivo.

    In Visual Studio fare clic con il pulsante destro del mouse packages.config in Esplora soluzioni e selezionare Esegui migrazione packages.config a PackageReference. Esaminare l'output della migrazione e risolvere eventuali avvisi prima di continuare.

  • Converti nel formato di progetto SDK-style.

    Passare il file di progetto al formato SDK. I progetti in stile SDK sono più concisi, supportano il multitargeting e sono necessari per .NET. Questa conversione può essere eseguita mentre la destinazione è ancora .NET Framework, quindi è un passaggio preparatorio sicuro. Molti strumenti di conversione gestiscono questa operazione automaticamente oppure è possibile eseguire la conversione manualmente sostituendo il contenuto del file di progetto con l'equivalente in stile SDK e aggiungendo nuovamente le proprietà necessarie.

  • Aggiornare le dipendenze NuGet.

    Aggiornare tutti i pacchetti NuGet alle versioni più recenti e preferire pacchetti destinati solo a .NET Standard 2.0, anziché ai pacchetti destinati solo a .NET Framework. In questo modo si riduce il rischio di blocchi di dipendenza quando si modifica il framework di destinazione. Esaminare le note sulla versione del pacchetto per eventuali modifiche di rilievo introdotte nelle versioni più recenti.

Tutti i suggerimenti precedenti assicurano che i progetti siano in uno stato corretto prima di eseguire l'aggiornamento a .NET.

Pacchetto di Compatibilità Windows

Uno dei problemi più comuni nella migrazione da .NET Framework è la mancanza di API. .NET Standard esclude deliberatamente le tecnologie che non possono funzionare in tutte le piattaforme, ad esempio il Registro di sistema Windows, WMI e reflection emit, in modo che tali API non siano disponibili per impostazione predefinita. Il Microsoft.Windows.Compatibility pacchetto NuGet riempie tale gap. Fornisce circa 20.000 API nelle aree tecnologiche seguenti:

  • Registro di sistema di Windows
  • Registro eventi di Windows
  • Strumentazione gestione Windows (WMI)
  • Contatori delle prestazioni di Windows
  • Servizi Directory
  • Elenchi di controllo di accesso di Windows
  • Servizi Windows
  • Crittografia di Windows
  • Windows Communication Foundation (WCF)
  • Porte, ODBC, CodeDom e altro ancora

Il pacchetto si trova sopra .NET Standard 2.0 ed è particolarmente utile durante la modernizzazione incrementale. Consente innanzitutto di compilare ed eseguire l'app in .NET, per poi affrontare in un secondo momento un refactoring più approfondito, senza dover riscrivere fin da subito l'uso delle API specifiche di Windows.

Per aggiungerlo al progetto, installare il Microsoft.Windows.Compatibility pacchetto NuGet:

dotnet add package Microsoft.Windows.Compatibility

Per informazioni dettagliate, vedere Usare il pacchetto di compatibilità Windows per convertire il codice per .NET.

Modifiche radicali

Le modifiche che causano un'interruzione sono una parte prevista di qualsiasi aggiornamento, indipendentemente dal fatto che vengano convertite da .NET Framework o spostate tra le versioni .NET. La verifica prima di iniziare impedisce sorprese in ritardo nella migrazione. Per informazioni di riferimento complete, vedere Modifiche di rilievo durante la conversione del codice.

Le modifiche che introducono incompatibilità si suddividono in diverse categorie e non tutte causano errori in fase di compilazione:

  • Le modifiche comportamentali influiscono sul funzionamento di un'API in fase di esecuzione. La firma rimane la stessa, ma cambiano l'output, le eccezioni sollevate o il comportamento interno. Questi sono i più difficili da intercettare perché non generano errori di compilazione.
  • Le modifiche alla compatibilità binaria influiscono sul fatto che gli assembly compilati esistenti continuino a funzionare senza ricompilazione. La rimozione o la modifica di una superficie API pubblica interrompe la compatibilità binaria.
  • Le modifiche alla compatibilità dell'origine richiedono di modificare il codice sorgente prima che venga compilato correttamente rispetto alla versione più recente.
  • Le modifiche alla compatibilità in fase di progettazione influiscono sul modo in cui i progetti si aprono e si comportano in Visual Studio o in altri ambienti di progettazione.

Quando si esegue la conversione da .NET Framework, si sta attraversando un gap di versione elevato, quindi l'elenco di potenziali modifiche è più lungo. Quando si esegue l'aggiornamento tra versioni di .NET, ad esempio da .NET 6 a .NET 9, l'ambito è più ristretto, ma ogni versione tra può introdurre modifiche che influiscono sull'app. Esaminare le modifiche di rilievo per ogni versione ignorata, non solo la versione di destinazione.

Le modifiche di rilievo specifiche per Windows Forms sono documentate in Modifiche di rilievo per la migrazione da .NET Framework a .NET. Filtra il riferimento delle modifiche che introducono incompatibilità in base all'intervallo di versioni interessato dall'aggiornamento e verifica le voci pertinenti per le API usate dall'app.

Attività successive all’aggiornamento

Dopo la compilazione e l'esecuzione dell'app in .NET, completare alcune attività di pulizia per rimuovere gli artefatti rimasti dall'aggiornamento.

Esaminare i pacchetti NuGet.

Il processo di aggiornamento potrebbe avere pacchetti aggiornati a versioni più recenti. Alcune di queste versioni più recenti rimuovono le dipendenze richieste dalle versioni precedenti. Dopo l'aggiornamento, controllare ogni pacchetto aggiornato e rimuovere eventuali dipendenze transitive che non sono più necessarie. Esaminare le note sulla versione per i pacchetti aggiornati per rilevare le modifiche comportamentali che non causano errori di compilazione.

Pulizia dei vecchi artefatti NuGet.

Se il progetto ha usato un packages.config file per gestire i riferimenti NuGet, non è più necessario dopo la migrazione al PackageReference formato. Eliminarlo dal progetto. È anche possibile eliminare la cartella locale packages nella directory del progetto o della soluzione. NuGet archivia ora i pacchetti in una cartella .nuget\packages della cache globale nel profilo utente.

Aggiornare System.Configuration i riferimenti.

La maggior parte delle app di .NET Framework fa riferimento System.Configuration direttamente. Dopo l'aggiornamento, il progetto potrebbe comunque portare tale riferimento. La System.Configuration libreria legge dal file app.config per la configurazione in fase di esecuzione. In .NET sostituirlo con il System.Configuration.ConfigurationManager pacchetto NuGet, che fornisce la stessa superficie API senza il riferimento diretto all'assembly del framework.

Modernizzare dopo l'aggiornamento

Una volta eseguita l'app in .NET, è possibile adottare modelli moderni che non sono disponibili in .NET Framework. Queste modifiche non sono necessarie per completare l'aggiornamento, ma migliorano la gestibilità e sfruttano gli investimenti attivi in .NET. Per un set più ampio di idee, vedere Modernizzare dopo l'aggiornamento a .NET da .NET Framework.

Eseguire la migrazione da App.config a appsettings.json.

.NET Framework usa App.config per le impostazioni di runtime, ad esempio le stringhe di connessione e la configurazione della registrazione. Le app .NET usano invece in genere appsettings.json, fornito dal pacchetto NuGet Microsoft.Extensions.Configuration. Molte librerie, inclusi i provider di log, hanno eliminato il supporto per App.config a favore di appsettings.json. La migrazione allinea l'app all'ecosistema e semplifica la configurazione quando si aggiungono nuove dipendenze.

App.config file continuano a funzionare in .NET tramite il System.Configuration.ConfigurationManager pacchetto NuGet, in modo da poter eseguire la migrazione incrementale. Per indicazioni, vedere Configurazione in .NET.

Sostituire il controllo WebBrowser con WebView2 (macchine virtuali Windows).

Il WebBrowser controllo è basato su Internet Explorer, che non è più supportato. macchine virtuali Windows per .NET può usare invece il WebView2 controllo in base a Microsoft Edge. WebView2 offre un controllo browser moderno e gestito attivamente con prestazioni, sicurezza e standard Web migliorati.

Aggiungere il pacchetto NuGet Microsoft.Web.WebView2 al progetto. A seconda della versione di Windows eseguita da un utente, potrebbe essere necessario installare il runtime WebView2 separatamente. Per altre informazioni, vedere Introduzione a Microsoft Edge WebView2.

Contenuti correlati

  • Last updated on