Creare un piano di conversione

Prima di passare direttamente al codice, dedicate del tempo a esaminare i passaggi consigliati per la pre-migrazione. Questo articolo offre informazioni dettagliate sui tipi di problemi che possono verificarsi e consente di decidere un approccio che abbia più senso.

Portare il codice

Prima di continuare, assicurarsi di seguire i prerequisiti per la conversione del codice. Sarà necessario decidere l'approccio migliore in base alle proprie esigenze, per poi iniziare a convertire il codice.

Affidarsi principalmente al compilatore

Questo approccio può rivelarsi la scelta migliore per progetti di piccole dimensioni o per progetti che non usano un numero elevato di API .NET Framework. L'approccio è semplice:

1. È possibile eseguire facoltativamente ApiPort sul progetto. Se esegui ApiPort, esamina il report per ottenere informazioni sui problemi che dovrai affrontare.
2. Copiare tutto il codice in un nuovo progetto .NET.
3. Facendo riferimento al report sulla portabilità, se generato, risolvere gli eventuali errori del compilatore fino a ottenere una compilazione completa del progetto.

Anche se non è strutturato, questo approccio incentrato sul codice spesso risolve rapidamente i problemi. Un progetto contenente solo modelli di dati potrebbe essere un candidato ideale per questo approccio.

Rimanere in .NET Framework fino a quando non vengono risolti i problemi di portabilità

Questo approccio potrebbe costituire la scelta migliore se si preferisce che il codice venga compilato durante l'intero processo. Di seguito viene riportata la descrizione di questo approccio:

1. Eseguire ApiPort su un progetto.
2. Risolvere i problemi usando diverse API portabili.
3. Prendere nota delle aree in cui non è possibile usare un'alternativa diretta.
4. Ripetere i passaggi precedenti per tutti i progetti da convertire, fino a quando non si è certi che ciascuno di essi sia pronto per essere copiato in un nuovo progetto .NET.
5. Copiare il codice in un nuovo progetto .NET.
6. Risolvete i problemi nei casi in cui avete notato che non esiste un'alternativa diretta.

Questo approccio attento è più strutturato rispetto alla semplice risoluzione degli errori del compilatore, ma è ancora relativamente incentrato sul codice e offre il vantaggio di consentirne sempre la compilazione. I modi in cui vengono corretti i problemi non risolvibili mediante il semplice uso di un'altra API possono variare notevolmente. È possibile che diventi necessario sviluppare un piano più completo per determinati progetti, approccio descritto nella sezione seguente.

Sviluppare un piano di attacco completo

Questo approccio potrebbe costituire la scelta migliore per progetti più complessi e di maggiori dimensioni, in cui per supportare .NET Core può essere necessaria la ristrutturazione del codice o la riscrittura completa di determinate aree. Di seguito viene riportata la descrizione di questo approccio:

1. Eseguire ApiPort su un progetto.

2. Determinare le posizioni in cui viene usato ciascun tipo non portabile e stabilire l'entità dell'impatto sulla portabilità complessiva.

   • Comprendere la natura di tali tipi. Sono in numero limitato, ma di uso frequente? Sono numerosi, ma usati raramente? Il loro uso è concentrato o distribuito in tutto il codice?
   • È possibile isolare facilmente il codice non portabile per gestirlo in modo più efficace?
   • È necessario effettuare il refactoring del codice?
   • Per i tipi non portabili, esistono API alternative che svolgono la stessa attività? Ad esempio, se si usa la classe WebClient, usare al suo posto la classe HttpClient.
   • Sono disponibili API portabili differenti che è possibile usare per eseguire un'attività, anche se non si tratta di una sostituzione vera e propria? Ad esempio, se si usa XmlSchema per l'analisi del codice XML ma non è necessaria l'individuazione dello schema XML, si potrebbero usare le API System.Xml.Linq e implementare manualmente l'analisi, invece di affidarsi a un'API.

3. Se sono presenti assembly difficili da trasferire, è opportuno lasciarli per il momento in .NET Framework? Di seguito sono indicati alcuni aspetti da considerare:

   • Alcune funzionalità della libreria possono non essere compatibili con .NET poiché sono basate in misura eccessiva su funzionalità specifiche di .NET Framework o di Windows. È opportuno trascurare momentaneamente tali funzionalità non compatibili e rilasciare una versione .NET temporanea della libreria con un numero minore di funzionalità fino a quando non sono disponibili le risorse per convertire le funzionalità?
   • Un'operazione di refactoring può essere utile?

4. La scrittura di una propria implementazione di un'API .NET Framework non disponibile è una scelta ragionevole?

   Si potrebbe prendere in considerazione di copiare, modificare e usare codice tratto dal codice sorgente di riferimento di .NET Framework. Il codice sorgente di riferimento è concesso in licenza con la licenza MIT, quindi esiste un ampio margine di libertà per usare il codice sorgente come base per il proprio codice. È sufficiente assicurarsi di aggiungere le attribuzioni appropriate per Microsoft nel codice.

5. Ripetere questo processo in base alle esigenze per i diversi progetti.

A seconda delle dimensioni della codebase, la fase di analisi può richiedere diverso tempo. Il tempo dedicato a questa fase per comprendere appieno la portata delle modifiche necessarie e per elaborare un piano consente in genere di risparmiare tempo alla fine, in particolare se la codebase è complessa.

Il piano può comportare la necessità di modifiche significative della codebase, mantenendo tuttavia come destinazione .NET Framework 4.7.2. Si tratta di una versione più strutturata dell'approccio precedente. La modalità di esecuzione del piano dipende dalle caratteristiche della codebase.

Approccio misto

È probabile che, in base al tipo di progetto, sia necessario combinare gli approcci descritti in precedenza. Effettuare le scelte più corrette per il progetto e la codebase.

Porta i tuoi test

Il modo migliore per assicurarsi per il codice convertito funzioni consiste nell'eseguirne il test durante la conversione in .NET. A tale scopo è necessario usare un framework di test che supporta la compilazione e l'esecuzione di test per .NET. Attualmente sono disponibili le tre opzioni seguenti:

• xUnit
  • Per iniziare
  • Strumento per trasferire un progetto MSTest in xUnit
• NUnit
  • Per iniziare
  • Post di blog sulla migrazione da MSTest a NUnit
• MSTest

Approccio consigliato

In definitiva, l'entità del lavoro di conversione dipende in larga misura dal modo in cui è strutturato il codice .NET Framework. Un buon metodo per convertire il codice consiste nell'iniziare con la base della libreria, ovvero i componenti fondamentali del codice. Può trattarsi di modelli di dati o di altri metodi e classi fondamentali usati dagli altri elementi in modo diretto o indiretto.

1. Adattare il progetto di test che testa lo strato della libreria che stai trasferendo attualmente.
2. Copiare la base della libreria in un nuovo progetto .NET e selezionare la versione di .NET Standard che si vuole supportare.
3. Apportare le modifiche necessarie per consentire la compilazione del codice. Molto probabilmente sarà necessario aggiungere le dipendenze dei pacchetti NuGet al file csproj.
4. Eseguire i test e apportare le modifiche eventualmente necessarie.
5. Selezionare il successivo livello di codice da convertire e ripetere i passaggi precedenti.

Iniziando con la base della libreria e spostandosi metodicamente dalla base testando ogni livello nel modo appropriato, la conversione diventa un processo sistematico in cui i problemi vengono isolati in un livello del codice alla volta.

Passaggi successivi

• Che cos'è la modernizzazione di GitHub Copilot
• Organizzare il progetto per il supporto sia di .NET Framework che di .NET Core