Im September haben wir die .NET Core-Unterstützung für die Erstellung von Windows-Desktopanwendungen, einschließlich WPF und Windows Forms, veröffentlicht. Seitdem haben wir uns gefreut, dass viele Entwickler ihre Geschichten über die Portierung von Desktop-Anwendungen auf .NET Core austauschen. Wir hören ständig Geschichten von .NET-Entwicklern von Windows-Desktopanwendungen darüber, wie sie ihr Geschäft mit WPF und Windows Forms unterstützen, insbesondere wenn der Desktop gewinnt, einschließlich:
- FOD-Anwendungen (Formulare über Daten) mit einer dichten Benutzeroberfläche
- Reaktionsschnelle Benutzeroberfläche mit geringer Latenz
- Anwendungen, die offline arbeiten müssen
- Anwendungen mit Abhängigkeiten von benutzerdefinierten Gerätetreibern
Werfen Sie einen Blick auf die Vorteile von .NET Core für die Erstellung von Windows-Anwendungen.
Warum ist Windows-Desktop auf .NET Core?
.NET Core (und in Zukunft .NET 5, das auf .NET Core basiert) wird die Zukunft von .NET sein. Wir bemühen uns, .NET Framework so lange wie möglich zu unterstützen. Es werden jedoch keine neuen Funktionen bereitgestellt, sondern nur .NET Core (und letztendlich .NET 5) hinzugefügt. Um die Windows-Desktop-Stapel zu verbessern und .NET-Desktop-Entwicklern die Möglichkeit zu geben, von allen zukünftigen Updates zu profitieren, haben wir Windows Forms und WPF für .NET Core eingeführt. Es handelt sich weiterhin nur um Windows-Technologien, da sie eng mit den Windows-APIs verwandt sind. Neben den plattformübergreifenden Funktionen bietet .NET Core viele weitere Funktionen, mit denen Desktopanwendungen verbessert werden können.
Zunächst werden alle Laufzeitverbesserungen und Sprachfunktionen nur in .NET Core und künftig in .NET 5 hinzugefügt. Ein gutes Beispiel hierfür ist C # 8, das in .NET Core 3.0 verfügbar wurde. Darüber hinaus werden .NET Core-Versionen von Windows Forms und WPF Teil der .NET 5-Plattform. Wenn Sie Ihre Anwendung auf .NET Core portieren, bereiten Sie sie auf .NET 5 vor.
Darüber hinaus bietet .NET Core Bereitstellungsflexibilität für Ihre Anwendungen mit neuen Optionen, die in .NET Framework nicht verfügbar sind, z.
- Parallele Bereitstellung Jetzt können Sie mehrere Versionen von .NET Core auf einem Computer installieren und auswählen, auf welche Version sich jede Ihrer Anwendungen konzentrieren soll.
- Offline-Bereitstellung. Sie können die .NET Core-Plattform mit Ihren Anwendungen bereitstellen und sind völlig unabhängig von der Endbenutzerumgebung - Ihre Anwendung verfügt über alles, was Sie für die Ausführung auf jedem Windows-Computer benötigen.
- Kleinere Anwendungsgrößen. In .NET Core 3 haben wir eine neue Funktion namens Linker (manchmal auch Trimmer genannt) eingeführt, die Ihren Code analysiert und in eine Offline-Bereitstellung nur die Assemblys aus .NET Core einbezieht, die für Ihre Anwendung erforderlich sind. Somit werden alle Plattformdetails, die in Ihrem Fall nicht verwendet werden, gelöscht.
- Einzelne EXE-Dateien. Sie können Ihre Anwendung und die .NET Core-Plattform in eine einzige EXE-Datei packen.
- Verbesserte Laufzeitleistung. .NET Core bietet viele Leistungsoptimierungen im Vergleich zu .NET Framework. Wenn Sie sich an den Verlauf von .NET Core erinnern, der ursprünglich für die Workloads im Web und auf dem Server erstellt wurde, können Sie nachvollziehen, ob Ihre Anwendung spürbare Vorteile aus der Laufzeitoptimierung ziehen kann. Insbesondere bei Desktopanwendungen, die in hohem Maße von Datei-E / A-, Netzwerk- und Datenbankoperationen abhängen, sind Leistungsverbesserungen für diese Szenarien wahrscheinlich. Einige Bereiche, in denen Sie möglicherweise keine wesentlichen Änderungen bemerken, beziehen sich auf die Renderleistung der Benutzeroberfläche oder den Anwendungsstart.
Durch Festlegen der Eigenschaften
<PublishSingleFile> ,
<RuntimeIdentifier> und
<PublishTrimmed> im Veröffentlichungsprofil können Sie die
<PublishTrimmed> eigenständige Anwendung als einzelne EXE-Datei bereitstellen, wie im folgenden Beispiel gezeigt.
<PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishSingleFile>true</PublishSingleFile> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishTrimmed>true</PublishTrimmed> </PropertyGroup>
Unterschiede zwischen .NET Framework-Desktop und .NET Core-Desktop
Bei der Entwicklung von Desktopanwendungen werden Sie keinen großen Unterschied zwischen den Versionen von WPF und Windows Forms für .NET Framework und .NET Core feststellen. Ein Teil unserer Bemühungen bestand darin, funktionale Ähnlichkeiten zwischen diesen Desktop-Plattformen bereitzustellen und die Zukunft von .NET Core zu verbessern.
WPF-Anwendungen werden in .NET Core vollständig unterstützt, und Sie können mit ihnen arbeiten, während wir an kleineren Updates und Verbesserungen arbeiten. Für Windows Forms wurde die Laufzeit vollständig auf .NET Core portiert, und das Team arbeitet derzeit am Windows Forms-Designer. Wir planen, es für das vierte Quartal 2020 vorzubereiten. Derzeit können Sie jedoch die vorläufige Version des Designers in
Visual Studio 16.4 Preview 3 oder höher überprüfen. Denken Sie daran, das Kontrollkästchen unter Extras-> Optionen-> Vorschau-Funktionen-> Vorschau von Windows Forms-Designer für .NET Core-Apps zu aktivieren und Visual Studio neu zu starten. Bitte beachten Sie, dass die Erfahrungen mit der Verwendung noch begrenzt sind, da die Arbeiten noch nicht abgeschlossen sind.
Wichtige Änderungen
Es gab einige
wichtige Änderungen an .NET Framework und .NET Core, aber der größte Teil des Codes für die Bereiche Windows Forms und WPF wurde auf dieselbe Weise in Core portiert. Wenn Sie zuvor Komponenten wie WCF-Client, Codezugriffssicherheit, Anwendungsdomänen, Interop und Remoting verwendet haben, müssen Sie den Code umgestalten, wenn Sie zu .NET Core wechseln möchten.
Beachten Sie Folgendes: Die Standardausgabepfade in .NET Core unterscheiden sich von den Pfaden in .NET Framework. Wenn Ihr Code also einige Annahmen zur Datei- / Ordnerstruktur der ausgeführten Anwendung enthält, fällt er möglicherweise in die Laufzeit.
Es gibt auch Änderungen an der Konfiguration von .NET-Funktionen. Anstatt die Datei
machine.config verwenden, verwendet .NET Core die Datei
<something>.runtimeconfig.json , die mit der Anwendung
<something>.runtimeconfig.json und denselben Hauptzweck und ähnliche Informationen hat. Einige Konfigurationen, wie
system.net ,
system.net oder
system.servicemodel , werden nicht unterstützt, sodass die Anwendungskonfigurationsdatei nicht geladen werden kann, wenn sie einen dieser Abschnitte enthält. Diese Änderung gilt für die
System.Diagnostics Ablaufverfolgung und für WCF-Clientskripts, die zuvor in der Regel mithilfe der XML-Konfiguration konfiguriert wurden. In .NET Core müssen Sie sie stattdessen in Code konfigurieren.
appSettings das Verhalten ohne
appSettings Trace-Typen und die WCF-
appSettings indem Sie Werte verwenden, die von einer
Microsoft.Extensions.Configuration Quelle oder von
appSettings .
Weitere Informationen zu den Unterschieden zwischen .NET Core und .NET Framework finden Sie in der
Dokumentation .
Um loszulegen
Sehen Sie sich diese kurzen Tutorials an:
Portierung von .NET Framework auf .NET Core
Starten Sie zunächst den
Portability Analyzer (Portability Analyzer) und aktualisieren Sie gegebenenfalls den Code, um eine 100% ige Kompatibilität mit .NET Core sicherzustellen. Hier finden Sie
Anweisungen zur Verwendung des Portabilitätsanalysators. . Wir empfehlen, dass Sie die Quellcodeverwaltung verwenden oder eine Sicherungskopie Ihres Codes erstellen, bevor Sie Änderungen an Ihrer Anwendung vornehmen, falls das Refactoring nach Ihren Wünschen fehlschlägt und Sie beschließen, zu Ihrem ursprünglichen Zustand zurückzukehren.
Wenn Ihre Anwendung vollständig mit .NET Core kompatibel ist, können Sie sie portieren. Als Ausgangspunkt können Sie das von uns erstellte Tool ausprobieren, um die Konvertierung Ihrer .NET Framework-Projekte in .NET Core zu automatisieren -
try-convert .
Es ist wichtig zu wissen, dass dieses Tool nur ein Ausgangspunkt für Ihre Reise zu .NET Core ist. Dies ist auch kein unterstütztes Microsoft-Produkt. Obwohl es Ihnen bei einigen mechanischen Aspekten der Migration behilflich sein kann, werden nicht alle Szenarien oder Projekttypen behandelt. Wenn Ihre Lösung Projekte enthält, die das Tool ablehnt oder nicht konvertieren kann, müssen Sie diese manuell übertragen. Keine Sorge, wir haben viele Lektionen vorbereitet (am Ende des Artikels).
Das Try-Convert-Tool versucht, die Projektdateien im alten Stil in das neue SDK-Format zu übertragen und die entsprechenden Projekte in .NET Core neu zu konfigurieren. Wir überlassen es Ihren Bibliotheken, die Plattform auszuwählen: .NET Core oder .NET Standard. Sie können eine davon in der Projektdatei angeben, indem Sie den Wert für
<TargetFramework> . Bibliotheken ohne .NET Core-spezifische Abhängigkeiten wie WPF oder Windows Forms können von der Auswahl von .NET Standard profitieren:
<TargetFramework>netstandard2.1</TargetFramework>
Damit können sie von Anrufern verwendet werden, die auf viele verschiedene .NET-Plattformen abzielen. Wenn die Bibliothek eine Funktion verwendet, für die .NET Core erforderlich ist (z. B. die Windows-Desktop-UI-API), sollte sich die Bibliothek auf .NET Core konzentrieren:
<TargetFramework>netcoreapp3.0</TargetFramework>
try-convert ist ein globales Tool, das Sie auf Ihrem Computer
installieren und dann über die CLI aufrufen können:
C:\> try-convert -p <path to your project>
oder
C:\> try-convert -w <path to your solution>
Wie bereits erwähnt, finden Sie hier Informationen zum manuellen Portieren der Anwendung, falls das Try-Convert-Tool in Ihrem Fall nicht funktioniert.
VideoDie Dokumentation
Siehe auch:
7 kostenlose Kurse für Entwickler