Lunga vita .NET

Microsoft ha già detto che .NET Core è il futuro di .NET, il che significa che se non hai avviato, dovrai iniziare a migrare le tue applicazioni .NET Framework esistenti su .NET Core. Esamineremo alcuni motivi per essere entusiasti di questo cambiamento e su come ottenere un vantaggio in movimento.
In un mondo in continua evoluzione di strumenti, framework e tendenze per gli sviluppatori, Microsoft vanta una straordinaria esperienza nel supportare l’ecosistema .NET e l’intera suite di prodotti che lo accompagna. Ecco perché il percorso che hanno deciso di intraprendere con .NET è sorprendente e un po ‘apprezzato. Se non l’hai ancora sentito, .NET 4.8 sarà l’ultima versione di .NET Framework. La prossima versione dopo .NET Core 3.0 sarà .NET 5.0, il che significa che .NET Core assumerà il manto di .NET. Uno dei principali obiettivi di .NET Core è sempre stato quello di unificare il framework in un unico runtime che si comporta in modo simile su tutte le piattaforme.

Con questo annuncio, Microsoft compirà due grandi passi, uno pianificato e l’altro non così pianificato. Il passaggio pianificato prevede che .NET Core diventi il ​​successore dell’eredità .NET. L’altro passaggio, che sarà un po ‘più agitato, è la mancanza di compatibilità all’indietro al 100% tra .NET 5 e .NET 4.8. (Al momento della stesura di questo documento, Microsoft si è impegnata ad avvicinarsi il più possibile alla parità API in .NET 5.0).

Esamineremo alcuni dei vantaggi di questo annuncio e come prepararci per questa modifica se il tuo codebase funziona ancora con .NET Framework 4.8.

Benefici
I principali vantaggi di questo annuncio sono che .NET Core è il futuro e qui per restare, così come alcuni miglioramenti delle prestazioni.

Il futuro di .NET è open source e illimitato. Mentre .NET si è diffuso ad altre piattaforme tramite Xamarin e Mono, .NET Core rappresenta un approccio unificato alla loro spinta multi-piattaforma. Insieme all’unità multi-piattaforma, Microsoft sta spingendo fortemente anche verso il sourcing di gran parte del proprio codice. Con open-source .NET, ha modificato i costi di licenza e hosting associati alla scelta di .NET e ha aperto la strada a startup e sviluppatori che non sono entusiasti delle lingue di “startup”. Un’altra menzione notevole è che Microsoft ha avuto la rara opportunità di riscrivere la propria lingua con tutti i vantaggi del senno di poi e dell’uso pratico del mondo reale. Non hanno sicuramente perso neanche questa opportunità; hanno apportato alcuni notevoli miglioramenti a .NET Core che potrai sfruttare durante la migrazione.

In particolare, hanno introdotto Span e memoria, che sono allocazioni contigue di memoria che vivono nello stack e consentono operazioni più veloci rispetto agli array esistenti. Il concetto è piuttosto semplice, ma il diavolo è nei dettagli. Sono disponibili per chiunque con cui giocare, ma sappi solo che Microsoft ha riscritto alcune delle sue API interne per sfruttare i miglioramenti delle prestazioni, quindi non dovrai imparare tutto il necessario per trarne vantaggio.

Attenti ai non starter
Prima di iniziare a prepararci per la migrazione, ci sono alcuni non principianti che, se rientrano in queste categorie, potrebbe essere necessario ripensare le soluzioni attuali o potenzialmente scavare in .NET Framework per la durata del progetto.

Al momento non ci sono piani per implementarli in .NET Core.

Non partiti
AppDomain
Remoting
Code Access Security (CAS)
Trasparenza della sicurezza (Silverlight)
System.EnterpriseServices
I passaggi per prepararsi alla migrazione
Ho fornito alcuni motivi per entusiasmarsi per il futuro di .NET, alcune avvertenze per sapere se questa migrazione si applica in modo appropriato alle tue esigenze e ora dobbiamo apportare alcune modifiche alle nostre basi di codice esistenti per essere pronti per la prossima versione.

Microsoft ha fatto un buon lavoro nello sviluppo di una serie di strumenti per aiutare con la migrazione.

Passaggio 1. Impostare il progetto come destinazione .NET Framework 4.7.2
Il primo passo può sembrare un passo indietro, ma ti consigliamo di impostare il tuo progetto su .NET Framework 4.7.2. Microsoft consiglia di utilizzare 4.7.2 poiché offre la disponibilità delle più recenti alternative API per i casi in cui lo standard .NET non supporta le API esistenti.

Noterai che ho lanciato casualmente .NET Standard senza entrare nei dettagli. .NET Standard è un insieme formale di API che devono essere disponibili su ogni implementazione .NET che ti consentirà di migrare senza interruzioni a .NET Core da .NET Standard.

Passaggio 2. Eseguire il codice tramite .NET Portability Analyzer
Dopo esserti assicurato che il tuo codice sia indirizzato a .NET Framework 4.7.2, è tempo di eseguire il codice tramite .NET Portability Analyzer .NET Portability Analyzer  (ApiPort) per determinare la quantità di lavoro necessaria per il porting della tua base di codice .NET Framework su .NET Core, .NET Standard, ASP.NET Core, NET Core + Platform Extensions o .NET Standard + Platform Extensions. Questo strumento è versatile poiché puoi utilizzarlo per analizzare la tua base di codice con diverse opzioni. Ti permette di specificare le versioni e ottenere molto granulare con i consigli.

Se ti capita di usare C #, puoi usare l’ analizzatore API per aiutarti ad analizzare il tuo codice. Sebbene questo strumento sia utile, non è specifico per il porting della base di codice su .NET Core: rientra sicuramente nella categoria più generale di strumenti che capita di rintracciare il codice obsoleto, ma può rintracciare alcuni problemi di portabilità.

Passaggio 3. Implementare il piano per il porting
A questo punto, hai una buona idea dell’ambito di lavoro richiesto per spostare la tua base di codice in .NET Core o almeno un potenziale percorso in avanti una volta finché i problemi di compatibilità non vengono risolti. Quando inizi il porting, ci sono due tecniche che puoi usare per fare progressi. Il primo sarebbe quello di copiare il codice in un progetto .NET Core e scegliere una versione di .NET Standard che si desidera indirizzare e fare riferimento ai riferimenti ApiPort su quali modifiche devono essere apportate, insieme all’eliminazione dei pacchetti NuGet necessari. La seconda opzione sarebbe quella di modificarlo in atto. L’approccio migliore si basa davvero sul tuo codice e su ciò che funziona per te.

Passaggio 4. Test
Se sei stato in grado di eseguire il porting del tuo codice, i passaggi successivi consistono nell’eseguire i test unitari sulla base di codice migrata per assicurarti che funzionino. Esistono solo tre librerie di test unità eseguite su .NET Core: MSTest, xUnit e NUnit.