Freigeben über

Übersicht über das Portieren von .NET Framework zu .NET

Dieser Artikel enthält eine Übersicht darüber, was Sie beim Portieren ihres Codes von .NET Framework zu .NET (früher .NET Core) berücksichtigen sollten. Das Übertragen von Projekten vom .NET Framework zu .NET ist für viele relativ einfach. Die Komplexität Ihrer Projekte bestimmt, wie viel Arbeit Sie nach der ersten Migration der Projektdateien ausführen müssen.

Projekte, bei denen das App-Modell in .NET verfügbar ist, z. B. Bibliotheken, Konsolen-Apps und Desktop-Apps, erfordern in der Regel wenig Änderungen. Projekte, die ein neues App-Modell erfordern, z. B. zum Wechsel zu ASP.NET Core von ASP.NET, erfordern mehr Arbeit. Viele Muster aus dem alten App-Modell weisen Entsprechungen auf, die während der Konvertierung verwendet werden können.

Windows-Desktoptechnologien

Viele anwendungen, die für .NET Framework erstellt wurden, verwenden eine Desktoptechnologie wie Windows Forms oder Windows Presentation Foundation (WPF). Sowohl Windows Forms als auch WPF sind in .NET verfügbar, aber sie bleiben windows-only-Technologien.

Berücksichtigen Sie die folgenden Abhängigkeiten, bevor Sie eine Windows Forms- oder WPF-Anwendung migrieren:

  • Project-Dateien für .NET verwenden ein anderes Format als .NET Framework.
  • Ihr Projekt verwendet möglicherweise eine API, die in .NET nicht verfügbar ist.
  • Steuerelemente und Bibliotheken von Drittanbietern wurden möglicherweise nicht zu .NET portiert und bleiben nur für .NET Framework verfügbar.
  • Ihr Projekt verwendet eine Technologie, die in .NET nicht mehr verfügbar ist .

.NET verwendet die Open-Source-Versionen von Windows Forms und WPF und enthält Verbesserungen über .NET Framework.

Lernprogramme zum Migrieren Ihrer Desktopanwendung zu .NET finden Sie in einem der folgenden Artikel:

Windows-spezifische APIs

Anwendungen können weiterhin native Bibliotheken über P/Invoke auf Plattformen aufrufen, die von .NET unterstützt werden. Diese Technologie ist nicht auf Windows beschränkt. Wenn die Bibliothek, auf die Sie verweisen, jedoch Windows-spezifisch ist, z. B. eine user32.dll oder kernel32.dll, funktioniert der Code nur unter Windows. Für jede Plattform, auf der Ihre App ausgeführt werden soll, müssen Sie entweder plattformspezifische Versionen finden oder ihren Code generisch genug für die Ausführung auf allen Plattformen machen.

Beim Portieren einer Anwendung von .NET Framework zu .NET hat Ihre Anwendung wahrscheinlich eine Bibliothek verwendet, die von .NET Framework bereitgestellt wird. Viele APIs, die in .NET Framework verfügbar waren, wurden nicht zu .NET portiert, da sie auf Windows-spezifische Technologie basieren, z. B. die Windows-Registrierung oder das GDI+-Zeichnungsmodell.

Das Windows Compatibility Pack stellt einen großen Teil der .NET Framework-API-Oberfläche für .NET bereit und wird über das Microsoft.Windows.Compatibility NuGet-Paket bereitgestellt.

Weitere Informationen finden Sie unter Verwenden des Windows Compatibility Packs zum Portieren von Code zu .NET.

.NET Framework-Kompatibilitätsmodus

Der .NET Framework-Kompatibilitätsmodus wurde in .NET Standard 2.0 eingeführt. Im Kompatibilitätsmodus können .NET Standard- und .NET-Projekte auf .NET Framework-Bibliotheken verweisen, als ob sie für das Zielframework des Projekts kompiliert wurden. Einige .NET-Implementierungen unterstützen jedoch möglicherweise einen größeren Teil von .NET Framework als andere. Beispielsweise erweitert .NET Core 3.0 den .NET Framework-Kompatibilitätsmodus auf Windows Forms und WPF. Das Verweisen auf .NET Framework-Bibliotheken funktioniert nicht für alle Projekte, z. B. wenn die Bibliothek WPF-APIs verwendet, aber die Blockierung vieler Portierungsszenarien wird aufgehoben. Weitere Informationen finden Sie unter Analysieren Sie Ihre Abhängigkeiten, um Code vom .NET Framework zu .NET zu portieren.

Das Verweisen auf .NET Framework-Bibliotheken funktioniert in allen Fällen nicht, da sie davon abhängt, welche .NET Framework-APIs verwendet wurden und ob diese APIs vom Zielframework des Projekts unterstützt werden. Außerdem funktionieren einige .NET Framework-APIs nur unter Windows. Der .NET Framework-Kompatibilitätsmodus entsperrt viele Portierungsszenarien, Aber Sie sollten Ihre Projekte testen, um sicherzustellen, dass sie auch zur Laufzeit funktionieren. Weitere Informationen finden Sie unter "Analysieren der Abhängigkeiten, um Code aus dem .NET Framework zu portieren zu".

Zielframeworkänderungen in SDK-Formatprojekten

Wie bereits erwähnt, verwenden die Projektdateien für .NET ein anderes Format als .NET Framework, das als SDK-Format bezeichnet wird. Auch wenn Sie nicht von .NET Framework zu .NET wechseln, sollten Sie die Projektdatei weiterhin auf das neueste Format aktualisieren. Die Möglichkeit zum Angeben eines Zielframeworks unterscheidet sich in SDK-Formatprojekten. In .NET Framework wird die <TargetFrameworkVersion> Eigenschaft mit einem Moniker verwendet, der die Version von .NET Framework angibt. .NET Framework 4.7.2 sieht z. B. wie der folgende Codeausschnitt aus:

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

Ein SDK-Formatprojekt verwendet eine andere Eigenschaft, um das Zielframework, die <TargetFramework> Eigenschaft, zu identifizieren. Beim Anvisieren des .NET Framework beginnt der Moniker mit net und endet mit der Version des .NET Framework ohne Punkte. Der Moniker für .NET Framework 4.7.2 lautet beispielsweise net472.

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

Eine Liste aller Zielmoniker finden Sie unter Target Frameworks in SDK-Style-Projekten.

Nicht verfügbare Technologien

Es gibt einige Technologien in .NET Framework, die in .NET nicht vorhanden sind:

  • Anwendungsdomänen

    Das Erstellen zusätzlicher Anwendungsdomänen wird nicht unterstützt. Verwenden Sie für die Codeisolation separate Prozesse oder Container als Alternative.

  • Fernkommunikation

    Remoting wird für die Kommunikation über Anwendungsdomänen hinweg verwendet, die nicht mehr unterstützt werden. Für einfache Kommunikation zwischen Prozessen sollten Sie die Mechanismen prozessübergreifender Kommunikation (Inter-Process Communication, IPC) als Alternative zu Remoting berücksichtigen, z. B. die Klassen System.IO.Pipes oder MemoryMappedFile. Für komplexere Szenarien sollten Sie Frameworks wie StreamJsonRpc oder ASP.NET Core (entweder mit gRPC - oder RESTful-Webdiensten) in Betracht ziehen.

    Da Remoting nicht unterstützt wird, werden Aufrufe von BeginInvoke() und EndInvoke() bei Delegatenobjekten PlatformNotSupportedException werfen.

  • Codezugriffssicherheit (Code Access Security, CAS)

    CAS war eine Sandkastentechnik, die von .NET Framework unterstützt wird, in .NET Framework 4.0 jedoch veraltet ist. Sie wurde durch Sicherheitstransparenz ersetzt und wird in .NET nicht unterstützt. Verwenden Sie stattdessen vom Betriebssystem bereitgestellte Sicherheitsgrenzen, z. B. Virtualisierung, Container oder Benutzerkonten.

  • Sicherheitstransparenz

    Ähnlich wie BEI CAS wird die Sandkastentechnik für Sicherheitstransparenz für .NET Framework-Anwendungen nicht mehr empfohlen und wird in .NET nicht unterstützt. Verwenden Sie stattdessen vom Betriebssystem bereitgestellte Sicherheitsgrenzen, z. B. Virtualisierung, Container oder Benutzerkonten.

  • System.EnterpriseServices

    System.EnterpriseServices (COM+) wird in .NET nicht unterstützt.

  • Windows Workflow Foundation (WF)

    WF wird in .NET nicht unterstützt. Eine Alternative finden Sie unter CoreWF.

Weitere Informationen zu diesen nicht unterstützten Technologien finden Sie unter .NET Framework-Technologien, die auf .NET 6+ nicht verfügbar sind.

Plattformübergreifend

.NET (früher als .NET Core bezeichnet) ist als plattformübergreifend konzipiert. Wenn Ihr Code nicht von Windows-spezifischen Technologien abhängt, kann er auf anderen Plattformen wie macOS, Linux und Android ausgeführt werden. Dieser Code enthält Projekttypen wie:

  • Bibliotheken
  • Konsolenbasierte Tools
  • Automatisierung
  • ASP.NET Webseiten

.NET Framework ist eine Nur-Windows-Komponente. Wenn Ihr Code Windows-spezifische Technologien oder APIs verwendet, z. B. Windows Forms und WPF, kann der Code weiterhin auf .NET ausgeführt werden, aber nicht auf anderen Betriebssystemen ausgeführt werden.

Es ist möglich, dass Ihre Bibliothek oder konsolenbasierte Anwendung plattformübergreifend verwendet werden kann, ohne viel zu ändern. Wenn Sie zu .NET portieren, sollten Sie dies berücksichtigen und Ihre Anwendung auf anderen Plattformen testen.

Die Zukunft von .NET Standard

.NET Standard ist eine formale Spezifikation von .NET-APIs, die für mehrere .NET-Implementierungen verfügbar sind. Die Motivation hinter .NET Standard bestand darin, eine größere Uniformität im .NET-Ökosystem zu schaffen. Ab .NET 5 wurde ein anderer Ansatz zur Erstellung von Uniformität eingeführt, und dieser neue Ansatz beseitigt die Notwendigkeit von .NET Standard in vielen Szenarien. Weitere Informationen finden Sie unter .NET 5+ und .NET Standard.

.NET Standard 2.0 war die letzte Version zur Unterstützung von .NET Framework.

Tools zur Unterstützung der Portierung

Anstatt eine Anwendung manuell vom .NET Framework zu .NET zu portieren, können Sie verschiedene Tools verwenden, um einige Aspekte der Migration zu automatisieren. Das Portieren eines komplexen Projekts ist selbst ein komplexer Prozess. Die Tools können bei dieser Reise hilfreich sein.

Auch wenn Sie ein Tool zum Portieren Ihrer Anwendung verwenden, sollten Sie die Überlegungen beim Portieren in diesem Artikel lesen.

.NET-Upgradeassistent

Der .NET-Upgrade-Assistent ist ein Befehlszeilentool, das auf verschiedenen Arten von .NET Framework-Apps ausgeführt werden kann. Es wurde entwickelt, um das Upgrade von .NET Framework-Apps auf .NET zu unterstützen. Nach dem Ausführen des Tools erfordert die App in den meisten Fällen mehr Aufwand, um die Migration abzuschließen. Das Tool enthält die Installation von Analyzern, die bei der Durchführung der Migration helfen können. Dieses Tool funktioniert für die folgenden Typen von .NET Framework-Anwendungen:

  • Windows Forms
  • WPF (Windows Presentation Foundation)
  • ASP.NET MVC
  • Konsole
  • Klassenbibliotheken

Dieses Tool verwendet die anderen in diesem Artikel aufgeführten Tools, z. B. try-convert, und führt den Migrationsprozess durch. Weitere Informationen zum Tool finden Sie im Überblick über den .NET-Upgrade-Assistenten.

try-convert

Das try-convert Tool ist ein globales .NET-Tool, das ein Projekt oder eine gesamte Lösung in das .NET SDK konvertieren kann, einschließlich des Verschiebens von Desktop-Apps in .NET. Dieses Tool wird jedoch nicht empfohlen, wenn Ihr Projekt über einen komplizierten Buildprozess verfügt, z. B. benutzerdefinierte Vorgänge, Ziele oder Importe.

Weitere Informationen finden Sie im try-convert GitHub-Repository.

Analysetool für die Plattformkompatibilität

Die Plattformkompatibilitätsanalyse analysiert, ob Sie eine API verwenden, die zur Laufzeit einen PlatformNotSupportedException Fehler auslöst. Obwohl die Suche nach einer dieser APIs unwahrscheinlich ist, wenn Sie von .NET Framework 4.7.2 oder höher wechseln, empfiehlt es sich, dies zu überprüfen. Weitere Informationen zu APIs, die Ausnahmen auf .NET auslösen, finden Sie unter APIs, die immer Ausnahmen in .NET Core auslösen.

Weitere Informationen finden Sie unter Plattformkompatibilitätsanalyse.

Überlegungen beim Portieren

Berücksichtigen Sie beim Portieren Ihrer Anwendung zu .NET die folgenden Vorschläge in der folgenden Reihenfolge:

✔️ ERWÄGEN SIE die Verwendung des .NET-Upgrade-Assistenten zum Migrieren Ihrer Projekte. Obwohl sich dieses Tool in der Vorschau befindet, automatisiert es die meisten manuellen Schritte, die in diesem Artikel beschrieben sind, und bietet Ihnen einen hervorragenden Ausgangspunkt für die Fortsetzung Ihres Migrationspfads.

✔️ ZIEHEN SIE IN BETRACHT, zuerst Ihre Abhängigkeiten zu untersuchen. Ihre Abhängigkeiten müssen auf .NET, .NET Standard oder .NET Core abzielen.

✔️ Migrieren Sie von einer NuGet -packages.config-Datei zu PackageReference den Einstellungen in der Projektdatei. Verwenden Sie Visual Studio, um die package.config Datei zu konvertieren.

✔️ ERWÄGEN Sie das Upgrade auf das neueste Projektdateiformat, auch wenn Sie Ihre App noch nicht portieren können. .NET Framework-Projekte verwenden ein veraltetes Projektformat. Obwohl das neueste Projektformat, das als SDK-Format bezeichnet wird, für .NET Core und darüber hinaus erstellt wurde, funktioniert das Format auch mit .NET Framework. Wenn Sie Ihre Projektdatei im neuesten Format haben, können Sie Ihre App in Zukunft portieren.

✔️ Retargetieren Sie Ihr .NET Framework-Projekt auf mindestens .NET Framework 4.7.2. Dadurch wird die Verfügbarkeit der neuesten API-Alternativen für Fälle sichergestellt, in denen .NET Standard vorhandene APIs nicht unterstützt.

✔️ ZIEHEN SIE IN BETRACHT, auf .NET 8 zu abzielen, bei dem es sich um eine long-term Support (LTS)-Version handelt.

✔️ DO-Ziel .NET 6+ für Windows Forms- und WPF-Projekte . .NET 6 und höhere Versionen enthalten viele Verbesserungen für Desktop-Apps.

✔️ ERWÄGEN Sie, .NET Standard 2.0 zu verwenden, wenn Sie eine Bibliothek migrieren, die auch mit .NET Framework-Projekten verwendet werden kann. Sie können Ihre Bibliothek auch multitargetieren und sowohl auf .NET Framework als auch auf .NET Standard abzielen.

✔️ Fügen Sie einen Verweis auf das NuGet-Paket "Microsoft.Windows.Compatibility" hinzu, wenn nach der Migration Fehler bei fehlenden APIs auftreten. Ein großer Teil der .NET Framework-API-Oberfläche ist über das NuGet-Paket für .NET verfügbar.

Siehe auch