Met de komst van .NET5 en de aankondiging van Microsoft te gaan stoppen met .NET Framework dient zich de vraag aan hoe bestaande .NET Framework applicaties kunnen worden gemigreerd naar het nieuwe .NET5. Dit blog probeert de migratiemogelijkheden die Microsoft biedt te behandelen en de mogelijke problemen en/of valkuilen te beschrijven die daarbij kunnen optreden.

Een stukje historie (en toekomst)

Het werd al een tijd verwacht maar nu is het dan zover: er komt geen nieuwe versie meer van het .NET Framework. De laatste versie van het .NET Framework is versie 4.8. Uiteraard zullen er voorlopig nog broodnodige patches uitgebracht worden, maar voor nieuwe features moet je echt overstappen naar het nieuwe .NET(5) voorheen bekend als .NET Core.

Onderstaand plaatje toont de historie in de ontwikkeling van de diverse framework versies die door Microsoft op de markt zijn gebracht:

Wanneer we inzoomen op het nieuwe .NET dan zien we dat Microsoft de volgende planning voor de releases uitgeeft:

Zoals is te zien zal er ieder jaar een nieuwe versie van .NET worden uitgebracht waarbij het iedere twee jaar zal gaan om een zogenaamde LTS (Long Term Support) versie. Deze LTS versies zullen door Microsoft voor een periode van drie jaar ondersteund worden. Daarnaast zal er ieder jaar een major versie worden uitgebracht. Voor deze versies zal de ondersteuningsperiode 15 maanden zijn.

Migratiepaden

Welke mogelijke paden voor een migratie kunnen worden gevolgd? In principe wordt geadviseerd “zo klein mogelijke” stappen te nemen voor een migratie. Overigens wordt wél aangeraden om te starten met de applicatie naar de meest recente .NET Framework versie te brengen, zijnde .NET Framework 4.8.

Onderstaand plaatje geeft dan de mogelijke migratiepaden weer:

Migratietools

Om je te helpen bij het migreren van applicaties van het oude .NET Framework naar het nieuwe .NET5 heb je een aantal tools tot je beschikking. Deze zijn onder te verdelen in twee categorieën:

  1. Portability analyzers

Dit zijn tools die een scan/analyse uitvoeren op je bestaande applicatie en die zijn bedoeld om inzicht te krijgen in … Een voorbeeld van zo’n analyzer is de API Portability Analyzer tool (API-port) van Microsoft. Deze tool geeft inzicht in de ondersteuning en de mate van integratie van de .NET API’s die worden gebruikt door een applicatie op verschillende .NET platformen. Denk hierbij vooral aan de 3rd party libraries die worden gebruikt.

API-port is als plug-in te installeren in Visual Studio wat het mogelijk maakt om vanuit de IDE een compatibiliteitsrapport voor de solution te genereren.

  1. Porting applicaties

Deze applicaties gaan naast de analyse ook daadwerkelijk een poging doen de applicatie te migreren naar een nieuwere versie .NET. Voorbeelden hiervan zijn het open source project try-convert (een eenvoudige CLI tool die helpt bij het migreren van .NET Framework-projecten naar .NET Core) en .NET Upgrade Assistent (waarvan try-convert een subonderdeel is)

Een diepere kijk in de tools

Zoals aangegeven onderscheiden we twee categorieën migratietools: de portability analyzers en de porting applicaties.

API-port

Naast dat API-port als CLI-tool gebruikt kan worden is deze analyzer beschikbaar als plug-in in Visual Studio. Hierdoor komt er bij selecteren van de solution een extra optie ter beschikking: “Analyze Solution Portability”

Zoals gezegd zal de analyzer geen werkelijke conversie gaan proberen uit te voeren maar genereert  het een rapport met als inhoud de compatibiliteit van de diverse projecten in de solution voor diverse targets waarnaar de conversie uitgevoerd kan worden. Tevens is in detail te zien welke onderdelen van de solution niet ondersteund worden bij een eventuele migratie. Daarnaast wordt in het overzicht ook aangegeven welke 3rd party libraries niet worden herkend en/of ondersteund:

API-port is met name geschikt om vooraf een beeld te krijgen tegen wat voor problemen men aan gaat lopen bij een migratie naar .NET5.

Try-convert

Net als de andere tools/analyzers wordt deze tool geïnstalleerd via .NET Core. Het is van de twee hier besproken migratietools de eenvoudige variant. Try-convert werkt via de CLI waarbij een aantal opties kunnen worden meegegeven zoals het path naar de te migreren solution/workspace en de optie om al dan niet een back-up te maken van de solution alvorens de migratie wordt uitgevoerd. In de praktijk is het echter aan te bevelen om een aparte migratie-branch te maken in de te migreren  repository zodat op eenvoudige wijze is na te gaan wat voor wijzigingen de migratietool uiteindelijk heeft doorgevoerd.

.NET Upgrade Assistent

De meest uitgebreide en door Microsoft aanbevolen migratietool is .NET Upgrade Assistent. Deze tool is nog in ontwikkeling en er worden op zeer regelmatige basis updates van uitgegeven. Ook deze tool heeft een CLI maar het grote verschil met het hiervoor genoemde try-convert is dat de gebruiker hier stapsgewijs door een aantal fases geleid wordt. Daarnaast doet de tool met name in solutions met meerdere projecten een aantal voorstellen zoals bijvoorbeeld de volgorde waarin de verschillende projecten zouden moeten worden gemigreerd (met het oog op afhankelijkheden tussen de projecten onderling). Iedere fase in het migratieproces zal worden voorzien van de nodige logging zodat de gebruiker steeds goed zicht blijft houden op mogelijke aandachtspunten en daarnaast zelf alternatieve keuzes kan maken.

De .NET Upgrade Assistent zal zo stap voor stap ieder project in de solution afwerken en zal daarbij ook de migratie/upgrade van bijvoorbeeld de NuGet packages voor zijn rekening nemen. Try-convert doet iets soortgelijks maar het voordeel wat de .NET Upgrade Assistent biedt is dat deze in zijn beslissing het target framework meeneemt. Hier schuilt echter wel een mogelijk gevaar in: omdat de .NET Upgrade Assistent zal proberen de NuGet packages te upgraden naar de meest recente versies kan het gebeuren dat je tegen nogal wat “breaking changes” aanloopt. Hier wordt door de migratietool verder geen rekening mee gehouden. De gebruiker zal dit later zelf moeten oplossen aan de hand van build errors die optreden.

Mogelijke pijnpunten/uitdagingen bij migratie

Het zal duidelijk zijn dat bij met name de meer uitgebreide solution met meerdere projecten een aantal problemen c.q. uitdagingen kunnen optreden. Het gaat dan met name om het soort project.

In het algemeen zullen er weinig problemen te verwachten zijn bij de backend libraries. Denk hierbij aan libraries zoals een datalibrary of een project wat de businesslogica bevat. Ook API’s (MVC projecten zonder Views 😉) vallen onder de projecten waarbij weinig problemen te verwachten zijn.

Iets anders wordt het als we gaan kijken naar front-end projecten zoals bijvoorbeeld een Winforms applicatie of een MVC project. Deze projecten raken de UI waar vooral met betrekking tot Razor views etc. problemen te verwachten zijn op het gebied jQuery en/of Bootstrap. Het zal daarom een afweging zijn wat met deze projecten te doen: migreren en daarna handmatig de fouten oplossen of een UI opnieuw ontwikkelen op basis van een nieuwe technologie zoals bijvoorbeeld Blazor.

Een ander mogelijk pijnpunt is de migratie van Entity Framework 6 naar EF Core. Met name de EDMX kan hier voor grote problemen zorgen. Daarnaast is het zo dat Microsoft EF6 compatible heeft gemaakt met .netstandard 2.1 waardoor er een keuze moet worden gemaakt: kiest met voor .netstandard 2.1 dan vervalt de compatibiliteit met .NET Framework 4.8. Kiest men daarentegen voor .NET Framework 4.8 dan is het niet compatible met .NET Core/.NET5. Dit is met name een lastige keuze als met kiest voor een geleidelijke overgang (waarbij men kiest voor het migreren van een aantal projecten per fase) en niet voor een “big bang” migratie.

Daarnaast is het zo dat een aantal technologieën gewoonweg niet meer beschikbaar zijn in .NET5:

  • Windows Communication Foundation (WCF)
  • Web Forms
  • Windows Workflow Foundation

Tot slot is het zo dat zich problemen kunnen voordoen met de al eerder genoemde 3rd party NuGet packages. Als stelregel kan hierbij gehanteerd worden dat wanneer een NuGet package compatible is met .netstandard dat er dan weinig problemen te verwachten zijn. Daarnaast zal het zo zijn dat met name de grotere vaak gebruikte packages al snel een .NET5 compatible versie zullen uitbrengen, vaak nog eerder dan dat Microsoft zo ver is.

Conclusie

Met de aankondiging van Microsoft te gaan stoppen met .NET Framework is het onvermijdelijk geworden na te gaan denken over een eventuele migratie naar een toekomstbestendige .NET versie zoals bijvoorbeeld .NET5. In dit blog heb ik willen aangeven wat voor mogelijkheden daar op dit moment voor op de markt zijn. Toegegeven dat het zeker nog niet de ultieme tools zijn en dat een gedegen onderzoek nodig is om uiteindelijk tot de juiste keuze te komen: migreren of greenfield ontwikkeling. Aan de andere kant: de mogelijkheden zijn er en de ontwikkelingen in migratietools volgen elkaar snel op. Aan u de keuze 😊.

Auteur: Pieter Baart © 2021 Bergler Competence Center[heading]Lees ook…[/heading][recent_posts style=”list” columns=”1″ cat=”weblog”][/vc_column][/vc_row]