Skapa en porteringsplan

Innan du går direkt in i koden, ta dig tid att gå igenom de rekommenderade stegen före migreringen. Den här artikeln ger dig insikt i vilka typer av problem du kan stöta på och hjälper dig att bestämma dig för en metod som passar bäst.

Porta koden

Se till att du följer kraven för portningskoden innan du fortsätter. Var redo att välja den bästa metoden för dig och börja portera kod.

Hantera främst kompilatorn

Den här metoden fungerar bra för små projekt eller projekt som inte använder många .NET Framework-API:er. Metoden är enkel:

1. Du kan också köra ApiPort i projektet. Om du kör ApiPort får du kunskap från rapporten om problem som du behöver åtgärda.
2. Kopiera all kod till ett nytt .NET-projekt.
3. När du refererar till portabilitetsrapporten (om den genereras) löser du kompileringsfel tills projektet har kompilerats helt.

Även om den är ostrukturerad löser den här kodfokuserade metoden ofta problem snabbt. Ett projekt som endast innehåller datamodeller kan vara en idealisk kandidat för den här metoden.

Stanna kvar på .NET Framework tills portabilitetsproblem har lösts

Den här metoden kan vara den bästa om du föredrar att ha kod som kompileras under hela processen. Metoden är följande:

1. Kör ApiPort i ett projekt.
2. Åtgärda problem med hjälp av olika API:er som är portabla.
3. Notera alla områden där du hindras från att använda ett direkt alternativ.
4. Upprepa föregående steg för alla projekt som du porterar tills du är säker på att var och en är redo att kopieras till ett nytt .NET-projekt.
5. Kopiera koden till ett nytt .NET-projekt.
6. Räkna ut eventuella problem där du noterade att det inte finns något direkt alternativ.

Den här noggranna metoden är mer strukturerad än att bara utarbeta kompilatorfel, men den är fortfarande relativt kodfokuserad och har fördelen att alltid ha kod som kompileras. Hur du löser vissa problem som inte kunde åtgärdas genom att bara använda ett annat API varierar kraftigt. Du kanske upptäcker att du behöver utveckla en mer omfattande plan för vissa projekt, som beskrivs i nästa metod.

Utveckla en omfattande attackplan

Den här metoden kan vara bäst för större och mer komplexa projekt, där omstruktureringskod eller helt omskrivning av vissa kodområden kan vara nödvändigt för att stödja .NET. Metoden är följande:

1. Kör ApiPort i ett projekt.

2. Förstå var varje icke-bärbar typ används och hur det påverkar den övergripande portabiliteten.

   • Förstå arten av dessa typer. Är de små i antal men används ofta? Är de stora i antal men används sällan? Är användningen koncentrerad eller sprids den i koden?
   • Är det enkelt att isolera kod som inte är portabel så att du kan hantera den mer effektivt?
   • Behöver du omstrukturera koden?
   • Finns det alternativa API:er som utför samma uppgift för de typer som inte är portabla? Om du till exempel använder WebClient klassen använder du HttpClient klassen i stället.
   • Finns det olika portabla API:er tillgängliga för att utföra en uppgift, även om det inte är en drop-in-ersättning? Om du till exempel använder XmlSchema för att parsa XML men inte kräver XML-schemaidentifiering kan du använda System.Xml.Linq API:er och implementera parsning själv i stället för att förlita dig på ett API.

3. Om du har sammansättningar som är svåra att porta, är det värt att lämna dem på .NET Framework för tillfället? Här är några saker att tänka på:

   • Du kan ha vissa funktioner i biblioteket som inte är kompatibla med .NET eftersom det förlitar sig för mycket på .NET Framework eller Windows-specifika funktioner. Är det värt att lämna den funktionen bakom dig för tillfället och släppa en tillfällig .NET-version av biblioteket med färre funktioner tills resurser är tillgängliga för att porta funktionerna?
   • Skulle en refaktor hjälpa till?

4. Är det rimligt att skriva en egen implementering av ett otillgängligt .NET Framework-API?

   Du kan överväga att kopiera, ändra och använda kod från .NET Framework-referenskällan. Referenskällkoden licensieras under MIT-licensen, så du har stor frihet att använda källan som grund för din egen kod. Se bara till att korrekt tillskriva Microsoft i din kod.

5. Upprepa den här processen efter behov för olika projekt.

Analysfasen kan ta lite tid beroende på storleken på din kodbas. Att spendera tid i den här fasen för att noggrant förstå omfattningen av de ändringar som behövs och för att utveckla en plan sparar vanligtvis tid i slutändan, särskilt om du har en komplex kodbas.

Din plan kan innebära att du gör betydande ändringar i din kodbas medan du fortfarande riktar in dig på .NET Framework 4.7.2. Det här är en mer strukturerad version av den tidigare metoden. Hur du kör din plan beror på din kodbas.

Blandad metod

Det är troligt att du kommer att blanda ovanstående metoder per projekt. Gör det som passar bäst för dig och för din kodbas.

Porta dina tester

Det bästa sättet att se till att allt fungerar när du har porterat koden är att testa koden när du porterar den till .NET. För att göra detta måste du använda ett testramverk som skapar och kör tester för .NET. För närvarande har du tre alternativ:

• xUnit
  • Kom igång
  • Verktyg för att konvertera ett MSTest-projekt till xUnit
• NUnit
  • Kom igång
  • Blogginlägg om migrering från MSTest till NUnit
• MSTest

Rekommenderat tillvägagångssätt

I slutändan beror portningsarbetet mycket på hur din .NET Framework-kod är strukturerad. Ett bra sätt att portera koden är att börja med bibliotekets bas , som är de grundläggande komponenterna i koden. Det kan vara datamodeller eller andra grundläggande klasser och metoder som allt annat använder direkt eller indirekt.

1. Portera testprojektet som testar lagret i ditt bibliotek som du portar för närvarande.
2. Kopiera över bibliotekets bas till ett nytt .NET-projekt och välj den version av .NET Standard som du vill stödja.
3. Gör de ändringar som behövs för att hämta koden som ska kompileras. Mycket av detta kan kräva att du lägger till NuGet-paketberoenden i csproj-filen.
4. Kör testerna och gör nödvändiga justeringar.
5. Välj nästa kodlager för att porta över och upprepa föregående steg.

Om du börjar med bibliotekets bas och flyttar ut från basen och testar varje lager efter behov, är portning en systematisk process där problem isoleras till ett kodlager i taget.

Nästa steg

• Vad är GitHub Copilot-modernisering
• Organisera projektet för att stödja både .NET Framework och .NET Core