Översikt över portning från .NET Framework till .NET
Den här artikeln innehåller en översikt över vad du bör tänka på när du portar din kod från .NET Framework till .NET (tidigare med namnet .NET Core). Det är relativt enkelt att portera till .NET från .NET Framework för många projekt. Komplexiteten i dina projekt avgör hur mycket arbete du ska utföra efter den första migreringen av projektfilerna.
Projekt där appmodellen är tillgänglig i .NET (till exempel bibliotek, konsolappar och skrivbordsappar) kräver vanligtvis liten förändring. Projekt som kräver en ny appmodell, till exempel att flytta till ASP.NET Core från ASP.NET, kräver mer arbete. Många mönster från den gamla appmodellen har motsvarigheter som kan användas under konverteringen.
Windows skrivbordstekniker
Många program som skapats för .NET Framework använder en skrivbordsteknik, till exempel Windows Forms eller Windows Presentation Foundation (WPF). Både Windows Forms och WPF har porterats till .NET, men dessa förblir Windows tekniker.
Överväg följande beroenden innan du migrerar ett Windows Forms- eller WPF-program:
- Project-filer för .NET använder ett annat format än .NET Framework.
- Ditt projekt kan använda ett API som inte är tillgängligt i .NET.
- Kontroller och bibliotek från tredje part kanske inte har porterats till .NET och är endast tillgängliga för .NET Framework.
- Ditt projekt använder en teknik som inte längre är tillgänglig i .NET.
.NET använder versionerna av Windows Forms och WPF med öppen källkod och innehåller förbättringar jämfört med .NET Framework.
Självstudier om hur du migrerar ditt skrivbordsprogram till .NET 6 finns i någon av följande artiklar:
Windows-specifika API:er
Program kan fortfarande P/Invoke-inbyggda bibliotek på plattformar som stöds av .NET. Den här tekniken är inte begränsad till Windows. Men om biblioteket som du refererar till är Windows specifikt, till exempel en user32.dll eller kernel32.dll, fungerar koden bara på Windows. För varje plattform som du vill att appen ska köras på måste du antingen hitta plattformsspecifika versioner eller göra koden tillräckligt generisk för att köras på alla plattformar.
När du portar ett program från .NET Framework till .NET använde ditt program förmodligen ett bibliotek som distribuerades med .NET Framework. Många API:er som var tillgängliga i .NET Framework porterades inte till .NET eftersom de förlitade sig på Windows specifik teknik, till exempel Windows Registry eller GDI+-ritningsmodellen.
Windows Compatibility Pack tillhandahåller en stor del av .NET Framework API-ytan till .NET och tillhandahålls via Microsoft.Windows. NuGet-paket för kompatibilitet.
Mer information finns i Använda Windows Compatibility Pack till portkod till .NET.
.NET Framework kompatibilitetsläge
Kompatibilitetsläget .NET Framework introducerades i .NET Standard 2.0. Med det här kompatibilitetsläget kan .NET Standard- och .NET 5+-projekt (och .NET Core 3.1) referera till .NET Framework bibliotek endast på Windows. Att referera .NET Framework bibliotek fungerar inte för alla projekt, till exempel om biblioteket använder API:er för Windows Presentation Foundation (WPF), men det avblockerar många portningsscenarier. Mer information finns i Analysera dina beroenden till portkod från .NET Framework till .NET.
Tekniker som inte är tillgängliga
Det finns några tekniker i .NET Framework som inte finns i .NET:
-
Det går inte att skapa ytterligare programdomäner. Använd separata processer eller containrar som ett alternativ för kodisolering.
-
Fjärrkommunikation används för kommunikation mellan programdomäner, som inte längre stöds. För enkel kommunikation mellan processer bör du överväga mekanismer för kommunikation mellan processer (IPC) som ett alternativ till fjärrkommunikation, till exempel System.IO.Pipes klassen eller MemoryMappedFile klassen. För mer komplexa scenarier bör du överväga ramverk som StreamJsonRpc eller ASP.NET Core (antingen med hjälp av gRPC- eller RESTful Web API-tjänster).
-
CAS var en sandbox-teknik som stöds av .NET Framework men är inaktuell i .NET Framework 4.0. Den ersattes av Säkerhetstransparens och stöds inte i .NET. Använd i stället säkerhetsgränser som tillhandahålls av operativsystemet, till exempel virtualisering, containrar eller användarkonton.
-
Precis som med CAS rekommenderas inte längre den här sandbox-tekniken för .NET Framework program och stöds inte i .NET. Använd i stället säkerhetsgränser som tillhandahålls av operativsystemet, till exempel virtualisering, containrar eller användarkonton.
-
System.EnterpriseServices (COM+) stöds inte i .NET.
Windows Workflow Foundation (WF)
WF stöds inte i .NET 5+ (inklusive .NET Core). Ett alternativ finns i CoreWF.
Mer information om dessa tekniker som inte stöds finns i .NET Framework tekniker som inte är tillgängliga på .NET Core och .NET 5+.
Plattformsoberoende
.NET (kallades tidigare .NET Core) är utformat för att vara plattformsoberoende. Om koden inte är beroende av Windows tekniker kan den köras på andra plattformar, till exempel macOS, Linux och Android. Detta inkluderar projekttyper som:
- Bibliotek
- Konsolbaserade verktyg
- Automation
- ASP.NET webbplatser
.NET Framework är en komponent med endast Windows. När koden använder Windows-specifika tekniker eller API:er, till exempel Windows Forms och Windows Presentation Foundation (WPF), kan koden fortfarande köras på .NET, men den körs inte på andra operativsystem.
Det är möjligt att ditt bibliotek eller konsolbaserade program kan användas plattformsoberoende utan att ändra mycket. När du porterar till .NET kanske du vill ta hänsyn till detta och testa ditt program på andra plattformar.
Framtiden för .NET Standard
.NET Standard är en formell specifikation av .NET-API:er som är tillgängliga för flera .NET-implementeringar. Motiveringen bakom .NET Standard var att skapa större enhetlighet i .NET-ekosystemet. Från och med .NET 5 har en annan metod för att fastställa enhetlighet antagits, och den här nya metoden eliminerar behovet av .NET Standard i många scenarier. Mer information finns i .NET 5 och .NET Standard.
.NET Standard 2.0 var den senaste versionen som hade stöd för .NET Framework.
Verktyg för att hjälpa till med portning
I stället för att manuellt portera ett program från .NET Framework till .NET kan du använda olika verktyg för att automatisera vissa aspekter av migreringen. Att porta ett komplext projekt är i sig en komplex process. De här verktygen kan vara till hjälp under den resan.
Även om du använder ett verktyg för att porta ditt program bör du läsa avsnittet Överväganden vid portning i den här artikeln.
Uppgraderingsassistenten för .NET
.NET Upgrade Assistant är ett kommandoradsverktyg som kan köras på olika typer av .NET Framework appar. Den är utformad för att hjälpa till med uppgradering av .NET Framework-appar till .NET 5. När du har kört verktyget kräver appen i de flesta fall mer arbete för att slutföra migreringen. Verktyget innehåller installation av analysverktyg som kan hjälpa dig att slutföra migreringen. Det här verktyget fungerar på följande typer av .NET Framework program:
- Windows Forms
- WPF
- ASP.NET MVC
- Konsol
- Klassbibliotek
Det här verktyget använder de andra verktygen som anges i den här artikeln och vägleder migreringsprocessen. Mer information om verktyget finns i Översikt över .NET Upgrade Assistant.
try-convert
Verktyget try-convert är ett globalt .NET-verktyg som kan konvertera ett projekt eller en hel lösning till .NET SDK, inklusive att flytta skrivbordsappar till .NET 5. Det här verktyget rekommenderas dock inte om projektet har en komplicerad byggprocess, till exempel anpassade uppgifter, mål eller importer.
Mer information finns i try-convert GitHub-lagringsplatsen.
.NET Portability Analyzer
.NET Portability Analyzer är ett verktyg som analyserar sammansättningar och tillhandahåller en detaljerad rapport om .NET-API:er som saknas för att programmen eller biblioteken ska vara portabla på dina angivna .NET-målplattformar.
Om du vill använda .NET Portability Analyzer i Visual Studio installerar du tillägget från Marketplace.
Mer information finns i .NET Portability Analyzer.
Analysverktyg för plattformskompatibilitet
Analysatorn för plattformskompatibilitet analyserar om du använder ett API som genererar en PlatformNotSupportedException vid körning. Även om detta inte är vanligt om du flyttar från .NET Framework 4.7.2 eller senare är det bra att kontrollera. Mer information om API:er som utlöser undantag på .NET finns i API:er som alltid utlöser undantag på .NET Core.
Mer information finns i Analysverktyg för plattformskompatibilitet.
Att tänka på vid portning
När du porterar ditt program till .NET bör du överväga följande förslag i ordning.
✔️ ÖVERVÄG att använda .NET Upgrade Assistant för att migrera dina projekt. Även om det här verktyget är i förhandsversion automatiserar det de flesta manuella stegen som beskrivs i den här artikeln och ger dig en bra utgångspunkt för att fortsätta din migreringsväg.
✔️ ÖVERVÄG att undersöka dina beroenden först. Dina beroenden måste vara inriktade på .NET 5, .NET Standard eller .NET Core.
✔️ MIGRERA FRÅN en NuGet packages.config-fil till PackageReference inställningarna i projektfilen. Använd Visual Studio för att konvertera package.config filen.
✔️ ÖVERVÄG att uppgradera till det senaste projektfilformatet även om du ännu inte kan portera din app. .NET Framework projekt använder ett inaktuellt projektformat. Även om det senaste projektformatet, som kallas SDK-projekt, skapades för .NET Core och senare, arbetar de med .NET Framework. Om du har projektfilen i det senaste formatet får du en bra grund för att portera din app i framtiden.
✔️ Gör om .NET Framework projektet till minst .NET Framework 4.7.2. Detta säkerställer tillgängligheten för de senaste API-alternativen i fall där .NET Standard inte stöder befintliga API:er.
✔️ ÖVERVÄG att rikta in dig på .NET 5 i stället för .NET Core 3.1. Även om .NET Core 3.1 har långsiktigt stöd (LTS) är .NET 5 det senaste och .NET 6 blir LTS när det släpps.
✔️ GÖR mål för .NET 5 för Windows Forms- och WPF-projekt. .NET 5 innehåller många förbättringar för skrivbordsappar.
✔️ ÖVERVÄG att rikta in dig på .NET Standard 2.0 om du migrerar ett bibliotek som också kan användas med .NET Framework projekt. Du kan också använda flera mål för ditt bibliotek med både .NET Framework och .NET Standard.
✔️ Lägg till referens till Microsoft.Windows. NuGet-paket för kompatibilitet om du efter migreringen får fel om saknade API:er. En stor del av .NET Framework API-ytan är tillgänglig för .NET via NuGet-paketet.