Panoramica di conversione da .NET Framework a .NET

  • Articolo

Questo articolo offre una panoramica di ciò che è necessario considerare quando si esegue la conversione del codice da .NET Framework a .NET (in precedenza chiamato .NET Core). La conversione in .NET da .NET Framework per molti progetti è relativamente semplice. La complessità dei progetti determina la quantità di lavoro da eseguire dopo la migrazione 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 ad ASP.NET Core da ASP.NET, richiedono più lavoro. Molti modelli derivanti dal modello di app precedente dispongono di 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). Sia Windows Form che WPF sono state convertite in .NET, ma rimangono tecnologie solo Windows.

Prendere in considerazione le dipendenze seguenti prima di eseguire la migrazione di 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 convertiti in .NET e rimanere 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 su .NET Framework.

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

API specifiche per Windows

Le applicazioni possono comunque usare il comando P/Invoke per 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 user32.dll o kernel32.dll, il codice funzionerà solo in Windows. Per ogni piattaforma in cui si vuole eseguire l'app, sarà necessario trovare le versioni specifiche della piattaforma o rendere il codice abbastanza generico da poter essere seguito in tutte le piattaforme.

Quando si esegue la conversione di un'applicazione da .NET Framework a .NET, è possibile che l'applicazione usi una libreria fornita da .NET Framework. Molte API disponibili in .NET Framework non sono state convertite in .NET perché si basavano su una 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 tramite il pacchetto NuGet Microsoft.Windows.Compatibility.

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

Modalità di compatibilità di .NET Framework

A partire da .NET Standard 2.0 è stata introdotta la modalità di compatibilità di .NET Framework. Questa modalità consente ai progetti .NET Standard e .NET di fare riferimento a librerie .NET Framework come se fossero state compilate per il framework di destinazione del progetto. Tuttavia, alcune implementazioni di .NET possono 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 se 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 proprietà <TargetFrameworkVersion> 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 proprietà <TargetFramework>. Quando la destinazione è .NET Framework, il moniker inizia con net e termina con la versione di .NET Framework senza alcun punto. Ad esempio, il moniker per la destinazione .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 applicazione

    La creazione di domini dell’applicazione aggiuntivi non è supportata. Per l'isolamento del codice, è consigliabile usare come alternativa processi e/o contenitori separati.

  • Comunicazione remota

    La comunicazione remota viene usata per la comunicazione tra domini dell’applicazione non più supportati. Per semplici comunicazioni tra processi, è possibile usare i meccanismi di comunicazione tra processi (IPC, Inter-Process Communication) in alternativa alla comunicazione remota, come la classe System.IO.Pipes o 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 genereranno PlatformNotSupportedException.

  • Sicurezza dall'accesso di codice (CAS, Code Access Security)

    CAS era una tecnica sandbox supportata da .NET Framework ma deprecata in .NET Framework 4.0. È stata sostituita da Trasparenza della sicurezza 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.

  • Trasparenza della sicurezza

    Analogamente a CAS, la tecnica sandbox per 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. Tale codice include tipi di progetto come:

  • Librerie
  • Strumenti basati su console
  • Automazione
  • Siti ASP.NET

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

È possibile che la libreria o l'applicazione basata su console possa essere usata in altre piattaforme senza dover subire molti cambiamenti. Quando si esegue la conversione a .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 della migrazione. La conversione di un progetto complesso è, di per 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 sulla conversione in questo articolo.

.NET Upgrade Assistant

.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 la migrazione. Lo strumento include l'installazione di analizzatori che consentono di completare la migrazione. Questo strumento funziona sui tipi di applicazioni .NET Framework seguenti:

  • WinForms
  • WPF
  • 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 migrazione. Per altre informazioni sullo strumento, vedere Panoramica dell’assistente di aggiornamento .NET.

try-convert

Lo strumento try-convert è uno strumento globale di .NET in grado di 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 repository try-convert di GitHub.

.NET Portability Analyzer

.NET Portability Analyzer è uno strumento che analizza gli assembly e fornisce un report dettagliato sulla portabilità. Segnala le API .NET mancanti nelle applicazioni o nelle librerie da convertire nelle piattaforme .NET di destinazione specificate.

Per usare .NET Portability Analyzer in Visual Studio, installare l'estensione dal marketplace.

Per altre informazioni, vedere .NET Portability Analyzer.

Analizzatore della compatibilità della piattaforma

L'analizzatore di compatibilità della piattaforma analizza se si usa o meno un'API che genererà un PlatformNotSupportedException in fase di esecuzione. Sebbene sia improbabile trovare una di queste API se si passa da .NET Framework 4.7.2 o versione successiva, è comunque 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 di compatibilità della piattaforma.

Considerazioni sulla conversione

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

✔️ TENERE PRESENTE l'uso di Assistente di aggiornamento .NET per eseguire la migrazione dei progetti. Anche se questo strumento è in anteprima, automatizza la maggior parte dei passaggi manuali descritti in questo articolo e offre un ottimo punto di partenza per continuare il percorso di migrazione.

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

✔️ ESEGUIRE la migrazione da un file nuGet packages.config alle impostazioni di PackageReference nel file di progetto. Usare Visual Studio per convertire il file package.config.

✔️ TENERE PRESENTE di effettuare 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 Progetto in stile SDK, è stato creato per .NET Core e versioni successive, funziona anche con .NET Framework. Avere il file di progetto nel formato più recente offre una buona base per convertire l'app in futuro.

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

✔️ TENERE PRESENTE la destinazione .NET 6, che è una versione di supporto a lungo termine (LTS).

✔️ TENERE PRESENTE la destinazione .NET 6+ per i progetti Windows Form e WPF. .NET 6 contiene molti miglioramenti per le app desktop.

✔️ TENERE PRESENTE la destinazione .NET Standard 2.0 se si esegue la migrazione di una libreria che potrebbe essere usata anche con progetti .NET Framework. È anche possibile impostare più destinazioni per la libreria, sia per .NET Framework che per .NET Standard.

✔️ AGGIUNGERE un riferimento al pacchetto NuGet Microsoft.Windows.Compatibility se in seguito alla migrazione si riscontrano errori di API mancanti. Una grande parte della superficie dell'API .NET Framework è disponibile per .NET tramite il pacchetto NuGet.

Vedi anche