Översikt över portning från .NET Framework till .NET

2025-06-03

Den här artikeln innehåller en översikt över vad du bör tänka på när du porterar 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 behöver gö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 som Windows Forms eller Windows Presentation Foundation (WPF). Både Windows Forms och WPF är tillgängliga i .NET, men de förblir windowsbaserade tekniker.

Tänk på följande beroenden innan du migrerar ett Windows Forms- eller WPF-program:

Projektfiler 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 portats till .NET och är endast tillgängliga för .NET Framework.
Projektet använder en teknik som inte längre är tillgänglig i .NET.

.NET använder versioner med öppen källkod av Windows Forms och WPF och innehåller förbättringar i .NET Framework.

För handledning om hur du migrerar ditt skrivbordsprogram till .NET kan du se en av följande artiklar:

Windows-specifika API:er

Program kan fortfarande P/Anropa interna 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 i 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 porterar ett program från .NET Framework till .NET använde ditt program förmodligen ett bibliotek som tillhandahålls av .NET Framework. Många API:er som var tillgängliga i .NET Framework portades inte till .NET eftersom de förlitade sig på Windows-specifik teknik, till exempel Windows-registret eller GDI+-ritningsmodellen.

Windows Compatibility Pack tillhandahåller en stor del av .NET Framework API-ytan till .NET och tillhandahålls via NuGet-paketet Microsoft.Windows.Compatibility.

Mer information finns i Använda Windows Compatibility Pack för att portkoda till .NET.

.NET Framework-kompatibilitetsläge

.NET Framework-kompatibilitetsläget introducerades i .NET Standard 2.0. Med kompatibilitetsläget kan .NET Standard- och .NET-projekt referera till .NET Framework-bibliotek som om de kompilerats för projektets målramverk. Vissa .NET-implementeringar kan dock ha stöd för en större del av .NET Framework än andra. Till exempel utökar .NET Core 3.0 .NET Framework-kompatibilitetsläget till Windows Forms och WPF. Att referera till .NET Framework-bibliotek fungerar inte för alla projekt, till exempel om biblioteket använder WPF-API:er, men det avblockerar många portningsscenarier. Mer information finns i Analysera dina beroenden till portkod från .NET Framework till .NET.

Att referera till .NET Framework-bibliotek fungerar inte i alla fall, eftersom det beror på vilka .NET Framework-API:er som användes och om dessa API:er stöds av projektets målramverk eller inte. Dessutom fungerar vissa .NET Framework-API:er endast i Windows. .NET Framework-kompatibilitetsläget avblockerar många portningsscenarier, men du bör testa dina projekt för att säkerställa att de också fungerar vid körning. Mer information finns i Analysera dina beroenden till portkod från .NET Framework till.

Målramverksändringar i SDK-liknande projekt

Som tidigare nämnts använder projektfilerna för .NET ett annat format än .NET Framework, så kallat SDK-format. Även om du inte flyttar från .NET Framework till .NET bör du fortfarande uppgradera projektfilen till det senaste formatet. Sättet att ange ett målramverk är annorlunda i SDK-liknande projekt. I .NET Framework <TargetFrameworkVersion> används egenskapen med en moniker som anger versionen av .NET Framework. Till exempel ser .NET Framework 4.7.2 ut som följande kodfragment:

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

Ett SDK-projekt använder en annan egenskap för att identifiera målramverket, egenskapen <TargetFramework> . När du riktar in dig på .NET Framework börjar monikern med net och slutar med versionen av .NET Framework utan några perioder. Monikern som ska riktas mot .NET Framework 4.7.2 är net472till exempel :

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

För en lista över alla målmoniker, se avsnittet Målramverk i SDK-stilprojekt.

Tekniker som inte är tillgängliga

Det finns några tekniker i .NET Framework som inte finns i .NET:

Programdomäner

Det går inte att skapa ytterligare programdomäner. Använd separata processer eller containrar som ett alternativ för kodisolering.
Fjärrstyrning

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 klassen System.IO.Pipes eller klassen MemoryMappedFile. 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).

Eftersom fjärrkommunikation inte stöds kastar anrop till BeginInvoke() och EndInvoke() på delegeringsobjekt PlatformNotSupportedException.
Kodåtkomstsäkerhet (CAS)

CAS var en sandbox-teknik som stöds av .NET Framework men 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.
Säkerhetstransparens

Precis som CAS rekommenderas inte längre sandbox-tekniken för säkerhetstransparens 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

System.EnterpriseServices (COM+) stöds inte i .NET.
Windows Workflow Foundation (WF)

WF stöds inte i .NET. För ett alternativ, se CoreWF.

Mer information om dessa tekniker som inte stöds finns i .NET Framework-tekniker som inte är tillgängliga på .NET 6+.

Plattformskompatibel

.NET (tidigare kallat .NET Core) är utformat för att vara plattformsoberoende. Om koden inte är beroende av Windows-specifika tekniker kan den köras på andra plattformar som macOS, Linux och Android. Sådan kod innehåller projekttyper som:

Bibliotek
Konsolbaserade verktyg
Automatisering
ASP.NET webbplatser

.NET Framework är en komponent endast för Windows. När koden använder Windows-specifika tekniker eller API:er, till exempel Windows Forms och 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. Motivationen bakom .NET Standard var att etablera 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 stödde .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 portera ett komplext projekt är i sig en komplex process. 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.

.NET Uppgraderingsassistent

.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. 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-formulär
WPF (Windows Presentation Foundation)
ASP.NET MVC
Konsol
Klassbibliotek

Det här verktyget använder de andra verktygen som anges i den här artikeln, till exempel try-convert, 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. 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.

Analysverktyg för plattformskompatibilitet

Analysverktyg för plattformskompatibilitet analyserar om du använder ett API som genererar en PlatformNotSupportedException vid körning. Det är osannolikt att hitta någon av dessa API:er om du flyttar från .NET Framework 4.7.2 eller senare, men det är 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 Analys av plattformskompatibilitet.

Överväganden 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 startpunkt för att fortsätta din migreringsväg.

✔️ ÖVERVÄG att undersöka dina beroenden först. Dina beroenden måste vara riktade mot .NET, .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 porta din app. .NET Framework-projekt använder ett inaktuellt projektformat. Även om det senaste projektformatet, som kallas SDK-liknande projekt, skapades för .NET Core och senare, fungerar formatet även med .NET Framework. Att ha projektfilen i det senaste formatet ger dig en bra grund för att portera din app i framtiden.

✔️ Gör om ditt .NET Framework-projekt till minst .NET Framework 4.7.2. Detta säkerställer tillgängligheten för de senaste API-alternativen för fall där .NET Standard inte stöder befintliga API:er.

✔️ ÖVERVÄG att rikta in dig på .NET 8, som är en version med långsiktigt stöd (LTS).

✔️ Satsa på .NET 6+ för Windows Forms och WPF-projekt. .NET 6 och senare versioner 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å multitarget ditt bibliotek med inriktning på både .NET Framework och .NET Standard.

✔️ Lägg till en referens till NuGet-paketet Microsoft.Windows.Compatibility 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.

Dela via