Erstellen Sie einen Portierungsplan

Bevor Sie direkt mit dem Code beginnen, nehmen Sie sich Zeit, um die empfohlenen Schritte vor der Migration durchzugehen. In diesem Artikel erhalten Sie Einen Einblick in die Arten von Problemen, die Sie möglicherweise feststellen können, und hilft Ihnen bei der Entscheidung über einen Ansatz, der am sinnvollsten ist.

Wichtig

API-Port wurde zugunsten der binären Analyse mit dem .NET Upgrade Assistant-Tool eingestellt. Der Back-End-Dienst von API Port wurde heruntergefahren. Daher kann das Tool nur offline verwendet werden. Weitere Informationen finden Sie in der Infodatei zu .NET API Port.

Code portieren

Stellen Sie sicher, dass Sie die Voraussetzungen für das Portieren von Code erfüllen, bevor Sie fortfahren. Seien Sie bereit, die für Sie am besten geeignete Vorgehensweise zu entscheiden, und beginnen Sie mit dem Portieren des Codes.

Wichtig

Der .NET-Upgrade-Assistent ist offiziell veraltet. Verwenden Sie stattdessen den GitHub Copilot-Modernisierungschat-Agent , der in Visual Studio 2026 und Visual Studio 2022 17.14.16 oder höher enthalten ist. Dieser Agent analysiert Ihre Projekte und Abhängigkeiten, erstellt einen schrittweisen Migrationsplan mit gezielten Empfehlungen und automatisierten Codefixes und führt einen Commit für jede Änderung durch, sodass Sie ein Rollback ausführen können. Es automatisiert allgemeine Portierungsaufgaben – Aktualisieren von Projektdateien, Ersetzen veralteter APIs und Beheben von Buildproblemen – sodass Sie schneller mit weniger manuellem Aufwand modernisieren können.

Sich hauptsächlich mit dem Compiler beschäftigen

Diese Vorgehensweise funktioniert gut für kleine Projekte oder für Projekte, die nicht viele .NET Framework-APIs verwenden. Der Ansatz ist einfach:

  1. Führen Sie optional ApiPort für Ihr Projekt aus. Wenn Sie ApiPort ausführen, erhalten Sie durch den Bericht Erkenntnisse über Probleme, die Sie behandeln müssen.
  2. Kopieren Sie Ihren gesamten Code in ein neues .NET-Projekt.
  3. Lösen Sie Compilerfehler, bis das Projekt vollständig kompiliert ist, während Sie auf den Portabilitätsbericht verweisen (wenn er generiert wurde).

Obwohl unstrukturiert, löst dieser codeorientierte Ansatz Probleme häufig schnell. Ein Projekt, das nur Datenmodelle enthält, kann möglicherweise ein idealer Kandidat für diesen Ansatz sein.

Bleiben Sie auf .NET Framework, bis Portabilitätsprobleme behoben werden

Dieser Ansatz könnte die beste Wahl sein, wenn Sie bevorzugen, dass der Code während des gesamten Prozesses kompiliert wird. Die Vorgehensweise sieht wie Folgt aus:

  1. Führen Sie ApiPort für ein Projekt aus.
  2. Beheben Sie Probleme mithilfe der verschiedenen APIs, die übertragbar sind.
  3. Notieren Sie alle Bereiche, in denen Sie daran gehindert werden, eine direkte Alternative zu verwenden.
  4. Wiederholen Sie die vorherigen Schritte für alle Projekte, die Sie portieren, bis Sie sicher sind, dass jedes Projekt in ein neues .NET-Projekt kopiert wurde.
  5. Kopieren Sie den Code in ein neues .NET-Projekt.
  6. Lösen sie alle Probleme, bei denen Sie sich notiert haben, dass keine direkte Alternative existiert.

Dieser sorgfältige Ansatz ist strukturierter als einfach Compilerfehler zu beheben, ist jedoch auch relativ codeorientiert und hat den Vorteil, dass immer Code vorhanden ist, der kompiliert wird. Die Herangehensweise, wie Sie bestimmte Probleme lösen, die nicht nur durch einfaches Verwenden einer anderen API behoben werden können, variiert stark. Möglicherweise müssen Sie einen umfassenderen Plan für bestimmte Projekte entwickeln. Dieser Ansatz wird im Folgenden behandelt.

Entwickeln eines umfassenden Vorgehensplans

Dieser Ansatz ist möglicherweise am besten für größere und komplexere Projekte geeignet, bei denen es womöglich nötig ist, Code umzustrukturieren oder bestimmte Bereiche komplett neu zu schreiben, um .NET zu unterstützen. Die Vorgehensweise sieht wie Folgt aus:

  1. Führen Sie ApiPort für ein Projekt aus.

  2. Sie müssen verstehen, wo jeder nicht portable Typ verwendet wird und wie sich dies auf die gesamte Portabilität auswirkt.

    • Verstehen Sie die Natur dieser Arten. Stellen sie nur eine geringe Anzahl dar, werden jedoch oft verwendet? Sind es viele, aber werden selten benutzt? Ist ihre Verwendung auf einen Punkt ausgerichtet oder im gesamten Code verteilt?
    • Ist es einfach, Code zu isolieren, der nicht portabel ist, damit Sie effektiver damit umgehen können?
    • Müssen Sie Ihren Code umgestalten?
    • Gibt es für nicht portable Typen alternative APIs, die die gleiche Aufgabe erfüllen? Wenn Sie z. B. die WebClient-Klasse verwenden, können Sie stattdessen die HttpClient-Klasse verwenden.
    • Gibt es unterschiedliche portable APIs, die für die Erfüllung der Aufgabe verfügbar sind, auch wenn es kein direkter Ersatz ist? Wenn Sie z. B. XmlSchema verwenden, um XML zu analysieren, aber keine XML-Schemasuche erforderlich ist, können Sie die System.Xml.Linq-APIs verwenden und das Analysieren selbst implementieren, anstatt auf eine API zu vertrauen.

  3. Wenn Sie über Assemblys verfügen, die schwierig zu portieren sind, lohnt es sich, diese vorerst im .NET Framework zu belassen? Nachfolgend sind einige Dinge aufgeführt, die Sie bedenken sollten:

    • Sie verfügen womöglich über einige Funktionen in Ihrer Bibliothek, die mit .NET inkompatibel sind, da sie zu stark auf einer bestimmten .NET Framework- oder Windows-Funktion basieren. Ist es also vorteilhaft, diese Funktionalität vorübergehend zu ignorieren, und temporär eine .NET-Version Ihrer Bibliothek mit weniger Funktionen zu veröffentlichen, bis die Ressourcen verfügbar sind, um die Funktionieren zu portieren?
    • Würde eine Umgestaltung helfen?

  4. Ist es sinnvoll, eine eigene Implementierung einer nicht verfügbaren .NET Framework-API zu schreiben?

    Sie könnten das Kopieren, Ändern und Verwenden von Code aus der .NET Framework-Verweisquelle in Erwägung ziehen. Der Quellcode für den Verweis wird unter der MIT-Lizenz lizenziert. Daher verfügen Sie über eine erhebliche Freiheit, die Quelle als Grundlage für Ihren eigenen Code zu verwenden. Stellen Sie nur sicher, dass Sie Microsoft ordnungsgemäß Ihrem Code zugeordnet haben.

  5. Wiederholen Sie diesen Vorgang für verschiedene Projekte nach Bedarf.

Die Analysephase kann je nach Größe Ihrer Codebasis einige Zeit dauern. Sie können sich auf lange Sicht Zeit in dieser Phase sparen, wenn Sie den Umfang der erforderlichen Änderungen verstehen und einen Plan entwickeln, besonders, wenn sie über eine komplexe Codebasis verfügen.

Ihr Plan kann wichtige Änderungen an Ihrer Codebase erfordern, während Sie noch immer auf .NET Framework 4.7.2 abzielen. Dies ist eine strukturiertere Version des vorherigen Ansatzes. Wie Sie Ihren Plan ausführen, hängt von Ihrer Codebasis ab.

Gemischter Ansatz

Es ist wahrscheinlich, dass Sie die oben genannten Vorgehensweisen jeweils pro Projekt mischen werden. Gehen Sie so vor, wie es für Sie und für Ihre Codebasis am sinnvollsten ist.

Portieren von Tests

Die beste Möglichkeit, um sicherzustellen, dass alles funktioniert, wenn Sie Ihren Code importiert haben, ist das Testen Ihres Codes beim Portieren zu .NET. Zu diesem Zweck müssen Sie ein Testframework verwenden, das Tests für .NET erstellt und ausführt. Derzeit stehen Ihnen drei Optionen zur Verfügung:

Die Arbeit für die Portierung hängt letztendlich schwer davon ab, wie Ihr .NET Framework-Code strukturiert ist. Eine gute Möglichkeit zum Portieren von Code ist der Beginn mit der Basis Ihrer Bibliothek, die aus den grundlegenden Komponenten Ihres Codes besteht. Dies sind womöglich Datenmodelle oder einige andere grundlegende Klassen und Methoden, die von allem anderen direkt oder indirekt verwendet werden.

  1. Portieren Sie das Testprojekt, das die Ebene Ihrer Bibliothek testet, die Sie derzeit portieren.
  2. Kopieren Sie die Basis Ihrer Bibliothek in ein neues .NET-Projekt, und wählen Sie die Version von .NET Standard aus, die unterstützt werden soll.
  3. Führen Sie alle erforderlichen Änderungen durch, sodass der Code kompiliert werden kann. Vieles davon erfordert möglicherweise das Hinzufügen von NuGet-Paketabhängigkeiten zu ihrer csproj-Datei.
  4. Führen Sie die Tests aus, und führen Sie erforderliche Anpassungen durch.
  5. Wählen Sie die nächste Codeebene aus, die portiert werden soll, und wiederholen Sie die vorherigen Schritte.

Wenn Sie mit der Basis Ihrer Bibliothek beginnen und sich von der Basis aus nach außen bewegen, und jede Ebene wie erforderlich testen, ist die Portierung ein schematischer Prozess, bei dem Probleme jeweils auf einer Codeebene isoliert werden.

Nächste Schritte

  • Last updated on