Condividi tramite

Panoramica della conversione da .NET Framework a .NET

Questo articolo offre una panoramica di ciò che è necessario considerare quando si esegue la conversione del codice da .NET Framework a .NET (in precedenza denominato .NET Core). La conversione in .NET da .NET Framework è relativamente semplice per molti progetti. La complessità dei progetti determina la quantità di lavoro da eseguire dopo l'aggiornamento iniziale dei file di progetto.

I progetti in cui il modello di app è disponibile in .NET, ad esempio librerie, app console e app desktop, richiedono in genere piccole modifiche. I progetti che richiedono un nuovo modello di app, ad esempio il passaggio a ASP.NET Core da ASP.NET, richiedono più lavoro. Molti modelli del modello di app precedente hanno equivalenti che possono essere usati durante la conversione.

Tecnologie desktop di Windows

Molte applicazioni create per .NET Framework usano una tecnologia desktop, ad esempio Windows Form o Windows Presentation Foundation (WPF). Windows Form e WPF sono disponibili in .NET, ma rimangono tecnologie solo Windows.

Considerare le dipendenze seguenti prima di aggiornare un'applicazione Windows Form o WPF:

  • I file di progetto per .NET usano un formato diverso da .NET Framework.
  • Il progetto potrebbe usare un'API non disponibile in .NET.
  • I controlli e le librerie di terze parti potrebbero non essere stati trasferiti in .NET e rimangono disponibili solo per .NET Framework.
  • Il progetto usa una tecnologia che non è più disponibile in .NET.

.NET usa le versioni open source di Windows Form e WPF e include miglioramenti di .NET Framework.

Per esercitazioni sull'aggiornamento dell'applicazione desktop a .NET, vedere uno degli articoli seguenti:

API specifiche di Windows

Le applicazioni possono comunque richiamare librerie native su piattaforme supportate da .NET. Questa tecnologia non è limitata a Windows. Tuttavia, se la libreria a cui si fa riferimento è specifica di Windows, ad esempio un user32.dll o kernel32.dll, il codice funziona solo in Windows. Per ogni piattaforma in cui si vuole eseguire l'app, è necessario trovare versioni specifiche della piattaforma o rendere il codice abbastanza generico da eseguire in tutte le piattaforme.

Quando si esegue la conversione di un'applicazione da .NET Framework a .NET, l'applicazione probabilmente usava una libreria fornita da .NET Framework. Molte API disponibili in .NET Framework non sono state convertite in .NET perché si basavano sulla tecnologia specifica di Windows, ad esempio Registro di sistema di Windows o il modello di disegno GDI+.

Windows Compatibility Pack fornisce una grande parte della superficie dell'API .NET Framework a .NET e viene fornita tramite il pacchetto NuGet Microsoft.Windows.Compatibility.

Per altre informazioni, vedere Usare Windows Compatibility Pack per convertire il codice in .NET.

Modalità di compatibilità di .NET Framework

La modalità di compatibilità di .NET Framework è stata introdotta in .NET Standard 2.0. La modalità di compatibilità consente ai progetti .NET Standard e .NET di fare riferimento alle librerie .NET Framework come se fossero state compilate per il framework di destinazione del progetto. Tuttavia, alcune implementazioni di .NET potrebbero supportare un blocco più grande di .NET Framework rispetto ad altri. Ad esempio, .NET Core 3.0 estende la modalità di compatibilità di .NET Framework a Windows Form e WPF. Il riferimento alle librerie .NET Framework non funziona per tutti i progetti, ad esempio se la libreria usa api WPF, ma sblocca molti scenari di conversione. Per altre informazioni, vedere Analizzare le dipendenze per convertire il codice da .NET Framework a .NET.

Il riferimento alle librerie .NET Framework non funziona in tutti i casi, perché dipende dalle API di .NET Framework usate e dal fatto che queste API siano supportate dal framework di destinazione del progetto. Inoltre, alcune API di .NET Framework funzioneranno solo in Windows. La modalità di compatibilità di .NET Framework sblocca molti scenari di conversione, ma è necessario testare i progetti per assicurarsi che funzionino anche in fase di esecuzione. Per altre informazioni, vedere Analizzare le dipendenze per convertire il codice da .NET Framework a .

Modifiche del framework di destinazione nei progetti in stile SDK

Come accennato in precedenza, i file di progetto per .NET usano un formato diverso da .NET Framework, noto come formato di progetto in stile SDK. Anche se non si passa da .NET Framework a .NET, è comunque necessario aggiornare il file di progetto al formato più recente. Il modo per specificare un framework di destinazione è diverso nei progetti in stile SDK. In .NET Framework la <TargetFrameworkVersion> proprietà viene usata con un moniker che specifica la versione di .NET Framework. Ad esempio, .NET Framework 4.7.2 è simile al frammento di codice seguente:

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

Un progetto in stile SDK usa una proprietà diversa per identificare il framework di destinazione, la <TargetFramework> proprietà . Quando si prende di mira .NET Framework, il moniker inizia con net e termina con la versione di .NET Framework senza punti. Ad esempio, il moniker per usare .NET Framework 4.7.2 è net472:

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

Per un elenco di tutti i moniker di destinazione, vedere Framework di destinazione nei progetti in stile SDK.

Tecnologie non disponibili

Esistono alcune tecnologie in .NET Framework che non esistono in .NET:

  • Domini di applicazione

    La creazione di altri domini applicazione non è supportata. Per l'isolamento del codice, usare processi o contenitori separati come alternativa.

  • Comunicazione remota

    Remoting viene usato per comunicare tra domini applicativi, che non sono più supportati. Per una semplice comunicazione tra processi, considera i meccanismi di comunicazione tra processi (IPC) come alternativa alla comunicazione remota, ad esempio la classe System.IO.Pipes o la classe MemoryMappedFile. Per scenari più complessi, prendere in considerazione framework come StreamJsonRpc o ASP.NET Core (usando gRPC o i servizi API Web RESTful).

    Poiché la comunicazione remota non è supportata, le chiamate a BeginInvoke() e EndInvoke() sugli oggetti delegati generano PlatformNotSupportedException.

  • Sicurezza dall'accesso al codice

    CAS era una tecnica di sandboxing supportata da .NET Framework, ma deprecata in .NET Framework 4.0. È stato sostituito dalla trasparenza della sicurezza e non è supportato in .NET. Usare invece i limiti di sicurezza forniti dal sistema operativo, ad esempio la virtualizzazione, i contenitori o gli account utente.

  • Trasparenza della sicurezza

    Analogamente a CAS, la tecnica di sandboxing per la trasparenza della sicurezza non è più consigliata per le applicazioni .NET Framework e non è supportata in .NET. Usare invece i limiti di sicurezza forniti dal sistema operativo, ad esempio la virtualizzazione, i contenitori o gli account utente.

  • System.EnterpriseServices

    System.EnterpriseServices (COM+) non è supportato in .NET.

  • Windows Workflow Foundation (WF)

    WF non è supportato in .NET. Per un'alternativa, vedere CoreWF.

Per altre informazioni su queste tecnologie non supportate, vedere Tecnologie .NET Framework non disponibili in .NET 6+.

Multipiattaforma

.NET (noto in precedenza come .NET Core) è progettato per essere multipiattaforma. Se il codice non dipende da tecnologie specifiche di Windows, può essere eseguito in altre piattaforme, ad esempio macOS, Linux e Android. Questo codice include tipi di progetto come:

  • Libraries
  • Strumenti basati su console
  • Automazione
  • ASP.NET siti

.NET Framework è un componente solo Windows. Quando il codice usa tecnologie o API specifiche di Windows, ad esempio Windows Form e WPF, il codice può comunque essere eseguito in .NET, ma non viene eseguito in altri sistemi operativi.

È possibile che la libreria o l'applicazione basata su console possa essere usata multipiattaforma senza cambiare molto. Quando si esegue la conversione in .NET, è possibile prendere in considerazione questa operazione e testare l'applicazione in altre piattaforme.

Il futuro di .NET Standard

.NET Standard è una specifica formale delle API .NET disponibili in più implementazioni .NET. La motivazione alla base di .NET Standard era quella di stabilire una maggiore uniformità nell'ecosistema .NET. A partire da .NET 5, è stato adottato un approccio diverso per stabilire l'uniformità e questo nuovo approccio elimina la necessità di .NET Standard in molti scenari. Per altre informazioni, vedere .NET 5+ e .NET Standard.

.NET Standard 2.0 è l'ultima versione per supportare .NET Framework.

Strumenti per facilitare la conversione

Anziché convertire manualmente un'applicazione da .NET Framework a .NET, è possibile usare diversi strumenti per automatizzare alcuni aspetti dell'aggiornamento. La trasposizione di un progetto complesso è, in sé, un processo complesso. Gli strumenti potrebbero essere utili in questo percorso.

Anche se si usa uno strumento per convertire l'applicazione, è consigliabile esaminare la sezione Considerazioni per la conversione in questo articolo.

Assistente alla modernizzazione delle app Copilot di GitHub

La modernizzazione delle app Copilot di GitHub è un assistente chat di GitHub Copilot che consente di pianificare e aggiornare i progetti a versioni più recenti di .NET, eseguire la migrazione ad Azure, aggiornare le dipendenze e applicare correzioni del codice. La migrazione di Azure è basata su applicazione e valutazione del codice per .NET

Questo assistente chat supporta i percorsi di aggiornamento seguenti:

  • Aggiornare i progetti dalle versioni precedenti di .NET alla versione più recente.
  • Aggiornare i progetti da .NET Framework alla versione più recente di .NET.
  • Modernizzare la codebase con nuove funzionalità.
  • Eseguire la migrazione di componenti e servizi ad Azure.

Funziona anche su vari tipi di progetto, ad esempio:

  • ASP.NET e tecnologie correlate, ad esempio MVC, Razor Pages, API Web
  • Blazor
  • Azure Functions
  • Fondazione per la Presentazione di Windows
  • Windows Forms
  • Librerie di classi
  • Applicazioni console

Quando usare:

Usare la modernizzazione delle app Copilot di GitHub quando si vuole un'esperienza end-to-end basata sull'intelligenza artificiale per aggiornare progetti e dipendenze di .NET Framework alla moderna .NET, coprendo valutazione, pianificazione, correzione e linee guida per la migrazione delle applicazioni ad Azure.

Valutazione dell'applicazione e del codice per .NET

L'applicazione e la valutazione del codice di Azure Migrate per .NET forniscono codice e analisi delle applicazioni, insieme ai consigli per la pianificazione delle distribuzioni cloud. Consente di eseguire in modo sicuro soluzioni critiche per l'azienda nel cloud offrendo una valutazione mirata allo sviluppatore del codice sorgente. Lo strumento fornisce anche consigli ed esempi per ottimizzare il codice e le configurazioni per Azure, seguendo le procedure consigliate del settore.

Questo strumento viene usato anche dalla modernizzazione delle app Copilot di GitHub per l'esperienza .NET.

Quando usare:

Usare l'applicazione Azure Migrate e lo strumento di valutazione del codice per il set di strumenti .NET per una valutazione e dei consigli per la migrazione di una base di codice esistente ad Azure. L'applicazione e la valutazione del codice di Azure Migrate sono essenzialmente un subset della modernizzazione dell'app GitHub Copilot per l'esperienza .NET.

Assistente per l'aggiornamento .NET

.NET Upgrade Assistant è uno strumento da riga di comando che può essere eseguito in diversi tipi di app .NET Framework. È progettato per facilitare l'aggiornamento delle app .NET Framework a .NET. Dopo aver eseguito lo strumento, nella maggior parte dei casi l'app richiederà più impegno per completare l'aggiornamento. Lo strumento include l'installazione di analizzatori che possono facilitare il completamento dell'aggiornamento. Questo strumento funziona sui tipi di applicazioni .NET Framework seguenti:

  • Windows Forms
  • WPF (Windows Presentation Foundation)
  • ASP.NET MVC
  • Console
  • Librerie di classi

Questo strumento usa gli altri strumenti elencati in questo articolo, ad esempio try-convert e guida il processo di aggiornamento. Per altre informazioni sullo strumento, vedere Panoramica di .NET Upgrade Assistant.

Quando usare:

Usare quando non è disponibile una soluzione basata su intelligenza artificiale come la modernizzazione delle app Copilot di GitHub.

try-convert

Lo try-convert strumento è uno strumento globale .NET che può convertire un progetto o un'intera soluzione in .NET SDK, incluso lo spostamento di app desktop in .NET. Tuttavia, questo strumento non è consigliato se il progetto ha un processo di compilazione complesso, ad esempio attività personalizzate, destinazioni o importazioni.

Per altre informazioni, vedere il try-convert repository GitHub.

Analizzatore della compatibilità della piattaforma

L'analizzatore di compatibilità della piattaforma analizza se si usa o meno un'API che genera un'eccezione PlatformNotSupportedException in fase di esecuzione. Anche se è improbabile trovare una di queste API se si passa da .NET Framework 4.7.2 o versione successiva, è consigliabile verificare. Per altre informazioni sulle API che generano eccezioni in .NET, vedere API che generano sempre eccezioni in .NET Core.

Per altre informazioni, vedere Analizzatore compatibilità della piattaforma.

Considerazioni sulla conversione

Quando si esegue la conversione dell'applicazione in .NET, prendere in considerazione i suggerimenti seguenti nell'ordine seguente:

✔️ Prendere in considerazione l'uso della modernizzazione dell'app GitHub Copilot per aggiornare i progetti. GitHub Copilot è potente per identificare e correggere le incompatibilità durante la conversione. Automatizza la maggior parte dei passaggi manuali descritti in questo articolo e offre un ottimo punto di partenza per continuare il percorso di aggiornamento.

✔️ Prendere in considerazione prima di tutto l'esame delle dipendenze. Le dipendenze devono essere destinate a .NET, .NET Standard o .NET Core.

✔️ Eseguire l'aggiornamento da un file NuGet packages.config alle PackageReference impostazioni nel file di progetto. Usare Visual Studio per convertire il package.config file.

✔️ È consigliabile eseguire l'aggiornamento al formato di file di progetto più recente anche se non è ancora possibile convertire l'app. I progetti .NET Framework usano un formato di progetto obsoleto. Anche se il formato di progetto più recente, noto come progetti in stile SDK, è stato creato per .NET Core e versioni successive, il formato funziona anche con .NET Framework. Avere il file di progetto nel formato più recente offre una buona base per convertire l'app in futuro.

✔️ Reindirizza il tuo progetto .NET Framework ad almeno .NET Framework 4.7.2. In questo modo si garantisce la disponibilità delle alternative API più recenti per i casi in cui .NET Standard non supporta le API esistenti.

✔️ Considera di puntare su .NET 8, che è una versione di supporto a lungo termine (LTS).

✔️ Punta a .NET 8+ per progetti Windows Forms e WPF. .NET 8 e versioni successive contengono molti miglioramenti per le app desktop.

✔️ Valutare l'utilizzo di .NET Standard 2.0 se stai aggiornando una libreria che potrebbe essere utilizzata anche con progetti .NET Framework. È anche possibile fare multitargeting della libreria, sia per .NET Framework sia per .NET Standard.

✔️ Aggiungi un riferimento al Microsoft.Windows.Compatibility NuGet package se, dopo aver migrato, ricevi errori di API mancanti. Una grande parte della superficie dell'API .NET Framework è disponibile per .NET tramite il pacchetto NuGet.

Vedere anche

  • Last updated on