Da circa tre mesi sono entrato nel team Blexin ed ho avuto la fortuna di partecipare ad un progetto in fase di startup. Il Cliente ci chiede la riscrittura di un applicativo WPF creato per lavorare offline con meccanismi di sincronizzazione dei dati con una versione Web e quindi accesso ai dati in tempo reale.

La richiesta è arrivata in concomitanza con il rilascio di .NET 5 e con il team abbiamo deciso di approfondire, in questo progetto, le novità introdotte sul campo ed ho pensato potessero essere utili a chi sta pensando ad una migrazione simile.

Vediamo quindi insieme le principali novità che Microsoft ha presentato il 10 Novembre alla .NET Conference e come si stia evolvendo il framework.

Nelle intenzioni di Microsoft c’è sempre stata l’idea di rendere possibile scrivere codice riutilizzabile (librerie) su più piattaforme (Web, Mobile, Desktop, IoT, Cloud e chi più ne ha più ne metta) e, nonostante .NET 5 sia un passo decisivo in quella direzione, la roadmap attuale ci dice che sarà .NET 6 a completare il processo.

La storia degli ultimi 20 anni è disseminata da tentativi, non sempre riusciti (leggi: Silverlight), di convergenza tra ambienti eterogenei. Facciamo un piccolo ripasso insieme di questi tentativi, perché dalla storia e dagli errori si deve sempre imparare.

Nel dicembre del 2006, grande fu la sorpresa per tutti gli sviluppatori Windows Form all’annuncio della versione beta di Silverlight: un plugin da installare sul browser che permetteva di far “girare” codice C# all’interno del browser stesso.

Varie versioni sono state rilasciate nel tempo, aumentando le funzionalità e la percentuale di codice che, potenzialmente, si poteva condividere. Ho sperimentato un paio di progetti con la versione 3.0 nel 2010, e devo dire che le premesse per un buon risultato c’erano tutte, con tanto di editor avanzato per la grafica e pattern MVVM nativo. Purtroppo, la dipendenza da un plugin esterno non fu accolto dal mercato positivamente che non ne colse le potenzialità. Oggi Silverlight è arrivato alla versione 5 e il supporto terminerà ad ottobre 2021.

Poi venne Xamarin, un’applicazione del framework Mono, il porting di .NET Framework su piattaforma Linux, Android, Mac OS e IOS. Ricordo la mia gioia quando, durante la conferenza Build del 2016, ci fu l’annuncio dell’acquisizione di Xamarin da parte di Microsoft e la disponibilità, a partire da Visual Studio 2017, di tutto il pacchetto Xamarin per lo sviluppo cross platform per i sistemi operativi mobile IOS, Android e Universal Windows Platform. Considerate che all’epoca Microsoft si considerava ancora un competitor per sistemi operativi Mobile ed aveva appena rilasciato Windows 10 Mobile. Il meccanismo che introdusse Xamarin per condividere il codice tra i vari ambiente fu duplice: Shared Project e Portable Class Library. La differenza tre le due implementazioni consisteva nella conoscenza dell’ambiente di deploy e delle relative primitive: nello Shared Project era possibile invocare metodo esclusivi della piattaforma di riferimento, mentre nella le Portable Class Library esisteva un subset di primitive comuni a tutte le piattaforme.

Le Portable Class Library sono state il seme che ha dato vita al progetto .Net Standard: un contratto di funzionalità comuni a cui le varie implementazioni del framework (.net Framework 4.x, .Net Core, Mono) si sottoscrivono. In fase di compilazione, viene referenziata l’implementazione opportuna per l’ambiente per cui si sta compilando.

Un grande lavoro è stato dedicato ai runtime coreFx e Mono, introducendo il supporto per Windows ARM64 e non solo. Consapevole dell’importanza che ricopre la containerizzazione, un impegno significativo in questa direzione da parte di Microsoft ha portato alla riduzione delle dimensioni delle immagini docker.

Con l’arrivo di .NET 5 le librerie hanno adesso un’implementazione di tutte le funzionalità su ogni runtime, mentre il progetto di unificazione della UI App di avere un unico progetto che in fase di compilazione venga “tipizzato” per l’ambiente di deploy, così come avviene per le librerie, è rimandato al prossimo anno. Per chi volesse cominciare a dare uno sguardo, qui trovate il link al repository del progetto MAUI.

Ma vediamo come tutte queste novità ci aiutano nel quotidiano e nel refactoring che stiamo affrontando.

Cominciamo con la memorizzazione dei dati: Entity Framework sia nella versione full framework che Core è supportato in .NET 5. Questo significa che anche librerie un po’ datate, di cui non si è pensato di fare il refactoring, scritte utilizzando Entity Framework 6.x, sono riutilizzabili. Ma EF Core 5, con la riscrittura totale di tutto il motore, ha un impatto significativo sulle performance, aspetto che non può essere trascurato nella scelta.

Tra le novità introdotte le più rilevanti sono sicuramente il mapping many-to-many delle tabelle (finalmente!) ed il supporto al logging configurabile con il metodo LogTo presente nel classe DbContextOptionsBuilder.

Il framework .NET 5 supporta tutte le novità introdotte dai linguaggi C# 9 e F# 5. Per i dettagli, se ve lo foste perso, vi consiglio l’articolo di Francesco.

Per il mondo servizi, le novità più consistenti introdotte in ASP.NET Core 5 riguardano il supporto a HTTP/2 e gRPC, che vanno a colmare il vuoto lasciato dall’assenza di WCF, che ci lascia definitivamente.

Per quando riguarda il mondo front-end Web server side, il supporto ai tipi record in Razor e il supporto nativo a Swagger sono sicuramente gli aspetti più interessanti. L’utilizzo dei record nel model binding ha sicuramente un impatto positivo sulla memoria e quindi anche sulle performance, mentre chi come me trova in Swagger uno strumento indispensabile si ritrova questa libreria nativamente nei propri progetti.

Assoluto protagonista di questo rilascio è sicuramente Blazor, che raggiunge la sua maturità con le novità introdotte da .NET 5 (qui trovate una guida introduttiva del nostro CEO/CTO Michele Aponte), con incremento delle performance, riduzione del payload del primo accesso e una serie di funzionalità quali:

• Componenti Nativi InputFile, InputRadio e InputRadioGroup;
• CSS Isolation, che permette di integrare componenti ti terze parti utilizzando semplicemente nuget senza dover aggiungere ulteriori riferimenti all’interno del progetto;
• JS Isolation, per isolare moduli Javascript;
• Miglioramento dell’esperienza di debug, sia in visual studio che in visual studio code
• Aggiornamento automatico del browser dopo le modifiche, questa funzione non è supportata se abilitato il debug;
• Componente Virtualize, che si occupa di renderizzare gli elementi di una lista di oggetti solo se sono visibili all’interno dell’area visibile della pagina.

Alcune significative novità sono state introdotte anche nella Command Language Interface (CLI) di .NET Core. L’opzione watch è stata estesa anche per i test, fornendo un’esperienza “Matrix Style” dei live Test. Ad ogni modifica del codice sul progetto di test o sui progetti da cui dipende verrà quindi eseguita la build e tutti i test.

Un obiettivo del progetto .NET Core è avere la possibilità di non installare software aggiuntivo sui server di destinazione, per questo motivo è stato introdotta la funzione di pubblicazione in unico file, dove vengono inglobate tutte le dipendenze della BCL necessarie al progetto.

Vediamo insieme le possibilità che questa opzione ci mette a disposizione.

dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true /p:PublishTrimmed=true

• PublishSingleFile produce un eseguibile con all’interno tutte le risorse del progetto ( immagini, resource, etc), in aggiunta al file .exe (in questo caso stiamo compilando per windows) ci sono anche le DLL della BCL necessari all’eseguibile. Questo vuol dire che possiamo copiare la cartella di output sulla macchina di destinazione e possiamo lanciarlo senza preoccuparci di dover installare il runtime.
• IncludeNativeLibrariesForSelfExtract le DLL della BCL necessarie all’eseguibile vengono inglobate all’interno del file .exe stesso.
• PublishTrimmed è una cura dimagrante delle dll della BCL: in fase di build il compilatore prende solo i metodi richiamati dal nostro codice; ovviamente, se il nostro progetto fa uso di reflection, non è auspicabile utilizzare questo parametro in quanto il compilatore non riesce a identificare i metodi chiamati dinamicamente.

Cosa non c’è e non ci sarà

In .NET 5 così come in .NET Core 3.1 non sarà presente ASP.NET Web Form, Windows Comunication Foundation (WCF) e Windows Workflow Foundation (WF). In alcuni casi abbiamo un’alternativa, come Blazor e gRPC, mentre esistono dei progetti open-source, non supportati ufficialmente da Microsoft, sia di WF (CoreWF) che di WCF (CoreWCF).

Conclusioni

Le novità che introduce .NET 5 con tutti i framework collegati (ASP.NET, Entity Framework, Blazor) e C# 9, possono rendere il lavoro dello sviluppatore sicuramente più agevole e veloce, con possibilità nuove da esplorare. Il lavoro sulle performance colloca l’ecosistema tra i più performanti sul mercato e, in un mondo che passa da poche grosse macchine a tante piccole unità che collaborano, questo aspetto ha sicuramente un ruolo fondamentale.

Spero di avervi almeno incuriosito a dare una possibilità a questa nuova release: se state pensando a una migrazione dei vostri progetti direi proprio che questo è un buon momento!

Al prossimo articolo. Buona Strada!