Übersicht über das Portieren von .NET Framework zu .NET
In diesem Artikel erhalten Sie einen Überblick über die Aspekte, die Sie beim Portieren von Code von .NET Framework zu .NET (früher als .NET Core bezeichnet) berücksichtigen sollten. Ein Portieren von .NET Framework zu .NET ist bei vielen Projekten relativ einfach. Der Aufwand, der nach der ersten Migration der Projektdateien anfällt, hängt von der Komplexität Ihrer Projekte ab.
Projekte, bei denen das App-Modell in .NET verfügbar ist (z. B. Bibliotheken, Konsolen- und Desktop-Apps), erfordern in der Regel nur wenige Änderungen. Projekte, für die ein neues App-Modell erforderlich ist, z. B. bei einer Umstellung von ASP.NET zu ASP.NET Core, sind aufwendiger. Viele Muster des alten App-Modells verfügen über Entsprechungen, die bei 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). Windows Forms und WPF wurden zwar zu .NET portiert, sind jedoch weiterhin reine Windows-Technologien.
Beachten Sie die folgenden Abhängigkeiten, bevor Sie eine Windows Forms- oder WPF-Anwendung migrieren:
- Projektdateien für .NET verwenden ein anderes Format als .NET Framework.
- Ihr Projekt kann eine API verwenden, die in .NET nicht verfügbar ist.
- Steuerelemente und Bibliotheken von Drittanbietern wurden möglicherweise nicht zu .NET portiert und sind weiterhin nur für .NET Framework verfügbar.
- Ihr Projekt verwendet eine in .NET nicht mehr verfügbare Technologie.
.NET verwendet die Open-Source-Versionen von Windows Forms und WPF und bietet Verbesserungen im Vergleich zu .NET Framework.
Tutorials zum Migrieren Ihrer Desktopanwendung zu .NET 6 finden Sie in einem der folgenden Artikel:
- Migrieren von .NET Framework-WPF-Apps zu .NET
- Migrieren von .NET Framework-Windows Forms-Apps zu .NET
Windows-spezifische APIs
Anwendungen können native Bibliotheken weiterhin mit 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. 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 auswählen oder den Code so generisch gestalten, dass er auf allen Plattformen ausgeführt werden kann.
Wenn Sie eine Anwendung von .NET Framework zu .NET portieren, hat die Anwendung wahrscheinlich eine Bibliothek verwendet, die mit dem .NET Framework bereitgestellt wurde. Viele APIs, die in .NET Framework verfügbar waren, wurden nicht zu .NET portiert, da Sie auf Windows-spezifischer Technologie wie der Windows-Registrierung oder dem GDI+-Zeichenmodell beruhten.
Das Windows Compatibility Pack macht einen Großteil der .NET Framework-API-Oberfläche für .NET verfügbar und wird über das Microsoft.Windows.Compatibility-NuGet-Paket bereitgestellt.
Weitere Informationen finden Sie unter Verwenden des Windows Compatibility Pack zum Portieren auf .NET.
Der .NET Framework-Kompatibilitätsmodus
Der .NET Framework-Kompatibilitätsmodus wurde mit .NET Standard 2.0 eingeführt. Mithilfe dieses Kompatibilitätsmodus können .NET Standard-Projekte und Projekte ab .NET 5 (und .NET Core 3.1) nur unter Windows auf .NET Framework-Bibliotheken verweisen. Das Verweisen auf .NET Framework-Bibliotheken funktioniert nicht bei allen Projekten. So funktioniert es z.B. nicht, wenn die Bibliothek Windows Presentation Foundation-APIs (WPF) verwendet. Dadurch werden jedoch viele Portierungsszenarios ermöglicht. Weitere Informationen finden Sie unter Analysieren von Abhängigkeiten zum Portieren von Code von .NET Framework zu .NET.
Nicht verfügbare Technologien
Einige Technologien aus .NET Framework sind in .NET nicht vorhanden:
-
Das Erstellen zusätzlicher Anwendungsdomänen wird nicht unterstützt. Für Codeisolierung verwenden Sie separate Prozesse oder Container als Alternative.
-
Remoting wird für die Kommunikation zwischen Anwendungsdomänen 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 Szenarios bieten sich Frameworks wie StreamJsonRpc oder ASP.NET Core (mit gRPC- oder RESTful-Web-API-Diensten) an.
Codezugriffssicherheit (Code Access Security, CAS)
CAS war ein Sandboxverfahren, das von .NET Framework unterstützt wurde, in .NET Framework 4.0 jedoch als veraltet eingestuft wurde. Es wurde durch Sicherheitstransparenz ersetzt und wird in .NET nicht unterstützt. Verwenden Sie stattdessen vom Betriebssystem bereitgestellte Sicherheitsgrenzen wie Virtualisierung, Container oder Benutzerkonten.
-
Wie bei CAS wird dieses Sandboxverfahren nicht mehr für .NET Framework-Anwendungen empfohlen und in .NET nicht unterstützt. Verwenden Sie stattdessen vom Betriebssystem bereitgestellte Sicherheitsgrenzen wie Virtualisierung, Container oder Benutzerkonten.
-
System.EnterpriseServices (COM+) wird in .NET nicht unterstützt.
Windows Workflow Foundation (WF)
WF wird ab .NET 5 (einschließlich .NET Core) nicht unterstützt. Eine Alternative finden Sie unter CoreWF.
Weitere Informationen zu diesen nicht unterstützten Technologien finden Sie unter .NET Framework-Technologien, die für .NET Core und .NET 5 und höher nicht verfügbar sind.
Plattformübergreifend
.NET (früher als .NET Core bezeichnet) ist plattformübergreifend konzipiert. Wenn Ihr Code nicht von Windows-spezifischen Technologien abhängig ist, kann er auf anderen Plattformen wie macOS, Linux und Android ausgeführt werden. Dies schließt Projekttypen wie die folgenden ein:
- Bibliotheken
- Konsolenbasierte Tools
- Automation
- ASP.NET-Sites
.NET Framework ist eine reine Windows-Komponente. Wenn Ihr Code Windows-spezifische Technologien oder APIs wie Windows Forms und Windows Presentation Foundation (WPF) verwendet, kann der Code weiterhin unter .NET, jedoch nicht unter anderen Betriebssystemen ausgeführt werden.
Möglicherweise kann Ihre Bibliothek oder konsolenbasierte Anwendung ohne umfassende Änderungen plattformübergreifend verwendet werden. Beim Portieren zu .NET 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 verschiedene .NET-Implementierungen verfügbar sind. Die Motivation hinter .NET Standard war es, mehr Einheitlichkeit im .NET-Ökosystem zu erreichen. Ab .NET 5 wird ein anderer Ansatz verfolgt, um diese Einheitlichkeit sicherzustellen. Bei diesem neuen Ansatz entfällt die Notwendigkeit von .NET Standard in vielen Szenarios. Weitere Informationen finden Sie unter .NET 5 und .NET Standard.
.NET Standard 2.0 war die letzte Version mit Unterstützung für .NET Framework.
Tools zur Unterstützung bei der Portierung
Anstatt eine Anwendung manuell von .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. Diese Tools können Ihnen dabei helfen.
Auch wenn Sie ein Tool zum Portieren Ihrer Anwendung verwenden, sollten Sie den Abschnitt Überlegungen zum Portieren in diesem Artikel lesen.
.NET-Upgrade-Assistent
Der .NET-Upgrade-Assistent ist ein Befehlszeilentool, das für verschiedene Arten von .NET Framework-Apps ausgeführt werden kann. Es soll ein Upgrade von .NET Framework-Apps auf .NET 5 vereinfachen. Nachdem Sie das Tool ausgeführt haben, ist zum Abschließen der App-Migration in den meisten Fällen mehr Aufwand erforderlich. Das Tool umfasst die Installation von Analysetools, die beim Durchführen der Migration helfen können. Dieses Tool kann mit den folgenden Typen von .NET Framework-Anwendungen verwendet werden:
- Windows Forms
- WPF
- ASP.NET MVC
- Konsole
- Klassenbibliotheken
Dieses Tool verwendet die anderen in diesem Artikel aufgeführten Tools und führt Sie durch den Migrationsvorgang. Weitere Informationen zum Installieren des Tools finden Sie unter Übersicht über den .NET-Upgrade-Assistenten.
try-convert
Das try-convert-Tool ist ein globales .NET-Tool, das ein Projekt oder eine ganze Projektmappe in das .NET SDK konvertieren kann, einschließlich des Verschiebens von Desktop-Apps zu .NET 5. Allerdings wird dieses Tool nicht empfohlen, wenn Ihr Projekt einen komplizierten Buildprozess, z. B. mit benutzerdefinierten Tasks, Zielen oder Importen, aufweist.
Weitere Informationen finden Sie im try-convert-GitHub-Repository.
.NET Portability Analyzer
.NET Portability Analyzer ist ein Tool, das Assemblys analysiert und einen detaillierten Bericht zu fehlenden .NET-APIs bereitstellt, damit die Anwendungen oder Bibliotheken auf die von Ihnen angegebenen .NET-Zielplattformen portiert werden können.
Um den .NET Portability Analyzer in Visual Studio zu verwenden, installieren Sie die Erweiterung aus dem Marketplace.
Weitere Informationen finden Sie unter .NET Portability Analyzer.
Analysetool für die Plattformkompatibilität
Mit dem Analysetool für die Plattformkompatibilität analysiert, ob Sie eine API verwenden, die zur Laufzeit eine PlatformNotSupportedException auslöst. Wenn Sie von .NET Framework 4.7.2 oder höher wechseln, ist dies zwar nicht häufig der Fall, aber eine Überprüfung ist dennoch eine gute Idee. Weitere Informationen zu APIs, die Ausnahmen in .NET auslösen, finden Sie unter APIs, die in .NET Core immer Ausnahmen auslösen.
Weitere Informationen finden Sie unter Analysetool für die Plattformkompatibilität.
Überlegungen zum Portieren
Wenn Sie Ihre Anwendung zu .NET portieren, sollten Sie die folgenden Vorschläge in der angegebenen Reihenfolge beachten.
✔️ OPTIONAL: Verwenden Sie ggf. den .NET-Upgrade-Assistenten zum Migrieren Ihrer Projekte. Obwohl sich dieses Tool noch in der Vorschauphase befindet, werden damit die meisten in diesem Artikel beschriebenen manuellen Schritte automatisiert, sodass Sie einen idealen Ausgangspunkt für die weiteren Migrationsschritte erhalten.
✔️ OPTIONAL: Untersuchen Sie die Abhängigkeiten. Ihre Abhängigkeiten müssen .NET 5, .NET Standard oder .NET Core als Ziel verwenden.
✔️ ERFORDERLICH: Migrieren Sie von einer NuGet-packages.config-Datei zu PackageReference-Einstellungen in der Projektdatei. Verwenden Sie Visual Studio zum Konvertieren der package.config-Datei.
✔️ OPTIONAL: Führen Sie ggf. ein Upgrade auf das aktuelle Projektdateiformat aus, auch wenn eine Portierung Ihrer App noch nicht möglich ist. .NET Framework-Projekte verwenden ein veraltetes Projektformat. Obwohl das aktuelle Projektformat, das als SDK-Format bezeichnet wird, für .NET Core und spätere Versionen erstellt wurde, funktioniert es mit .NET Framework. Wenn Ihre Projektdatei im aktuellen Format vorliegt, stellt dies eine gute Grundlage für das spätere Portieren ihrer App dar.
✔️ ERFORDERLICH: Legen Sie als neues Ziel Ihres .NET Framework-Projekts mindestens .NET Framework 4.7.2 fest. Dadurch wird die Verfügbarkeit der neuesten API-Alternativen für Fälle sichergestellt, in denen .NET Standard vorhandene APIs nicht unterstützt.
✔️ OPTIONAL: Legen Sie als Ziel nach Möglichkeit .NET 5 anstelle von .NET Core 3.1 fest. .NET Core 3.1 ist zwar eine Version mit langfristigem Support (Long-Term Support, LTS), .NET 5 ist jedoch die aktuelle Version, und .NET 6 wird bei Veröffentlichung eine LTS-Version sein.
✔️ ERFORDERLICH: Leben Sie bei Windows Forms- und WPF-Projekten .NET 5 als Ziel fest. .NET 5 bietet viele Verbesserungen für Desktop-Apps.
✔️ OPTIONAL: Legen Sie als Ziel ggf. .NET Standard 2.0 fest, wenn Sie eine Bibliothek migrieren, die möglicherweise auch mit .NET Framework-Projekten verwendet wird. Sie können für Ihre Bibliothek mit .NET Framework und .NET Standard auch mehrere Ziele festlegen.
✔️ ERFORDERLICH: Fügen Sie einen Verweis auf das Microsoft.Windows.Compatibility-NuGet-Paket hinzu, wenn nach der Migration Fehler aufgrund fehlender APIs auftreten. Ein großer Teil der .NET Framework-API-Oberfläche steht über das NuGet-Paket für .NET zur Verfügung.