Från .NET Framework till .NET 10: hur mycket arbete det är och hur du börjar

Applikationen på .NET Framework 4.x har rullat i tio år. Verksamheten bygger på den, kunderna använder den och ingen vill röra den. Sedan händer flera saker på en gång: ett nytt bibliotek du behöver stöder inte längre Framework, en bra kandidat tackar nej när hen hör vad jobbet handlar om, och driften kan inte flyttas till containrar eller till Linux.

Då är flytten till modern .NET inte längre en fråga om om, utan om hur och i vilken ordning.

Är det bråttom?

Ärligt talat: det brinner inte. .NET Framework 4.8.1 är den sista versionen, och Microsoft stöder den så länge den körs på en Windows-version som har support, utan något aviserat slutdatum. Säkerhetsuppdateringarna fortsätter att komma.

Men det är en återvändsgränd. Nya funktioner, bättre prestanda och nya bibliotek kommer bara i modern .NET, och .NET 10 är en version med långtidssupport (LTS) fram till november 2028. Varje år på Framework betyder mer kod att flytta senare och färre som vill underhålla den. Det billigaste tillfället att migrera är innan något tvingar dig.

Vad som är lätt att flytta, och vad som inte är det

Del av applikationen	Hur svårt	Hur
Bibliotek med affärslogik	Lätt	Det mesta av koden fungerar oförändrad, med det nya projektformatet
Entity Framework 6	Lätt	Körs även på modern .NET, och bytet till EF Core kan komma senare
Windows Forms och WPF	Medel	De går att flytta, men förblir applikationer som bara körs på Windows
ASP.NET MVC och Web API	Medel	Controllers är ungefär desamma, medan uppstart, filter och autentisering ändras
WCF-klienter	Medel	Det finns klientpaket för modern .NET
WCF-tjänster	Svårare	CoreWCF, eller byte till REST eller gRPC
Web Forms	Svårast	Finns inte i modern .NET, så skärmarna byggs om, till exempel i Blazor
AppDomains, Remoting, Code Access Security	Svårast	De finns inte, så den delen måste lösas på ett annat sätt

De flesta affärsapplikationer har något från varje rad, så en verklig uppskattning är alltid summan av delarna. Tabellen visar också var huvuddelen av arbetet ligger: i webblagret och de gamla teknikerna, inte i affärslogiken.

Så börjar du

1. InventeringProjekt, paket, beroenden
2. BibliotekNerifrån och upp, för båda världarna
3. WebblagerEn ny app framför den gamla
4. AvvecklingDen gamla delen stängs av

1. Inventering. Varje projekt, NuGet-paket och beroende, med delarna från tabellens nedersta rader markerade. Microsofts moderniseringsverktyg i GitHub Copilot hjälper dig att hitta det som inte kompilerar, men besluten om ordningen fattas fortfarande av en människa.

2. Bibliotek, nerifrån och upp. Först de projekt som inget annat är beroende av, sedan de som ligger ovanför. Varje bibliotek flyttas först till det nya projektformatet och byggs sedan för båda världarna samtidigt. På så sätt fortsätter den gamla applikationen att fungera medan ny kod redan använder samma bibliotek:

   <PropertyGroup>
     <TargetFrameworks>net48;net10.0</TargetFrameworks>   <!-- the same library for the old and the new app -->
   </PropertyGroup>

   Det som saknas i modern .NET och bara används på Windows täcks ofta av Microsofts Windows Compatibility Pack, med omkring tjugotusen API:er.

3. Webblagret, bit för bit. En ny ASP.NET Core-applikation placeras framför den gamla och tar över en route i taget, medan allt annat skickas vidare till den gamla appen. Användarna märker inte flytten, inloggning och session delas, och det finns ingen stor dag då allt byts ut på en gång. För Web Forms är det samma arbetssätt som vi beskriver på sidan om att flytta från Web Forms till Blazor.

4. Avveckling. När den sista routen har flyttats stängs den gamla applikationen av, och biblioteken kan släppa det gamla målet net48.

Hur mycket arbete det är

Det beror nästan helt på webblagret och tabellens nedersta rader. Bibliotek med affärslogik är ofta en fråga om dagar eller veckor. En mindre ASP.NET MVC-applikation tar oftast några veckor, och en stor Web Forms-applikation eller ett system byggt på WCF-tjänster några månader, men även då bit för bit, med applikationen i drift hela tiden.

Det dyraste sättet är att skriva om allt från grunden och samtidigt underhålla det gamla systemet. Varför en omskrivning från grunden sällan fungerar står i artikeln om teknisk skuld.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien, och att modernisera gamla .NET-system är något av det vi gör oftast. Vi börjar med en genomgång: en inventering av projekt och beroenden, vad som är lätt att flytta, vad som behöver byggas om och i vilken ordning, med en ungefärlig arbetsinsats för varje del. Det första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• Supportpolicy för .NET Framework, Microsoft
• Översikt över portning från .NET Framework till .NET, Microsoft Learn
• .NET Framework-tekniker som inte är tillgängliga i .NET, Microsoft Learn
• Använd Windows Compatibility Pack för att portera kod till .NET, Microsoft Learn
• GitHub Copilot-appmodernisering för .NET, Microsoft Learn
• CoreWCF, .NET Foundation