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 freuen wir uns, dass so viele Entwickler ihre Erfahrungen mit der Migration von Desktop-Anwendungen (und Steuerelementbibliotheken) nach .NET Core teilen. Wir hören ständig Geschichten von Entwicklern von .NET Windows-Desktops, die ihr Geschäft mit WPF und Windows Forms betreiben, insbesondere in Szenarien, in denen der Desktop glänzt, darunter:
- UI-dichte Formulare über Daten (FOD) -Anwendungen
- Reaktionsschnelle Benutzeroberfläche mit geringer Latenz
- Anwendungen, die offline / getrennt ausgeführt werden müssen
- Anwendungen mit Abhängigkeiten von benutzerdefinierten Gerätetreibern
Dies ist nur der Anfang für die Windows-Anwendungsentwicklung unter .NET Core. Lesen Sie weiter, um mehr über die Vorteile von .NET Core beim Erstellen von Windows-Anwendungen zu erfahren.
Warum Windows-Desktop auf .NET Core?
.NET Core (und in Zukunft .NET 5, das auf .NET Core aufbaut) wird die Zukunft von .NET sein. Wir verpflichten uns, .NET Framework in den kommenden Jahren zu unterstützen. Es werden jedoch keine neuen Funktionen bereitgestellt, sondern nur .NET Core (und möglicherweise .NET 5) hinzugefügt. Um Windows-Desktop-Stacks zu verbessern und .NET-Desktop-Entwicklern die Möglichkeit zu geben, von allen Updates der Zukunft zu profitieren, haben wir Windows Forms und WPF in .NET Core integriert. Sie bleiben weiterhin reine Windows-Technologien, da enge Abhängigkeiten zu Windows-APIs bestehen. .NET Core ist nicht nur plattformübergreifend, sondern bietet auch viele andere Funktionen, mit denen Desktopanwendungen verbessert werden können.
Zunächst werden alle Laufzeitverbesserungen und Sprachfunktionen nur in .NET Core und in Zukunft in .NET 5 hinzugefügt. Ein gutes Beispiel hierfür ist C # 8, das in .NET Core 3.0 verfügbar wurde. Außerdem werden die .NET Core-Versionen von Windows Forms und WPF Teil der .NET 5-Plattform. Indem Sie Ihre Anwendung heute auf .NET Core portieren, bereiten Sie sie auf .NET 5 vor.
.NET Core bietet außerdem Bereitstellungsflexibilität für Ihre Anwendungen mit neuen Optionen, die in .NET Framework nicht verfügbar sind, z.
- Side-by-Side-Bereitstellung. Jetzt können Sie mehrere .NET Core-Versionen auf demselben Computer haben und auswählen, auf welche Version Ihre Apps abzielen sollen.
- Eigenständige Bereitstellung. Sie können die .NET Core-Plattform mit Ihren Anwendungen bereitstellen und sind völlig unabhängig von Ihrer Endbenutzerumgebung - Ihre App verfügt über alles, was Sie für die Ausführung auf jedem Windows-Computer benötigen.
- Kleinere App-Größen. In .NET Core 3 haben wir eine neue Funktion namens Linker (manchmal auch als Trimmer bezeichnet) eingeführt, die Ihren Code analysiert und in Ihre eigenständige Bereitstellung nur die Assemblys aus .NET Core einbezieht, die für Ihre Anwendung benötigt werden. Auf diese Weise werden alle Plattformteile, die nicht für Ihren Fall verwendet werden, herausgeschnitten.
- Einzelne EXE-Dateien. Sie können Ihre App und die .NET Core-Plattform in einer einzigen EXE-Datei packen.
- Verbesserte Laufzeitleistung. .NET Core bietet im Vergleich zu .NET Framework viele Leistungsoptimierungen. Wenn Sie sich mit dem Verlauf von .NET Core beschäftigen, das ursprünglich für Web- und Server-Workloads erstellt wurde, ist es hilfreich zu verstehen, ob Ihre Anwendung möglicherweise spürbare Vorteile aus den Laufzeitoptimierungen zieht. Insbesondere bei Desktopanwendungen mit starken Abhängigkeiten von Datei-E / A, Netzwerk- und Datenbankoperationen werden in diesen Szenarien wahrscheinlich Leistungsverbesserungen zu verzeichnen sein . Einige Bereiche, in denen Sie möglicherweise keine großen Änderungen bemerken, betreffen die Renderleistung der Benutzeroberfläche oder die Startleistung der Anwendung.
Durch Festlegen der Eigenschaften
<PublishSingleFile> ,
<RuntimeIdentifier> und
<PublishTrimmed> im Veröffentlichungsprofil können Sie eine zugeschnittene 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
Während der Entwicklung von Desktopanwendungen werden Sie keinen großen Unterschied zwischen den .NET Framework- und .NET Core-Versionen von WPF und Windows Forms feststellen. Ein Teil unserer Bemühungen bestand darin, eine funktionale Parität zwischen diesen Plattformen im Desktop-Bereich bereitzustellen und die .NET Core-Erfahrung in Zukunft zu verbessern. WPF-Anwendungen werden in .NET Core vollständig unterstützt und können sofort verwendet werden, während wir an kleineren Updates und Verbesserungen arbeiten. Für Windows Forms ist der Laufzeitbereich vollständig auf .NET Core portiert und das Team arbeitet am Windows Forms-Designer. Wir planen, es bis zum vierten Quartal 2020 fertig zu stellen, und für den Moment können Sie die Preview-Version des Designers in
Visual Studio 16.4 Preview 3 oder höher auschecken. Vergessen Sie nicht, 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 bedenken Sie, dass die Erfahrung vorerst begrenzt ist, da an ihr gearbeitet wird.
Veränderungen brechen
Es gibt einige
wichtige Änderungen zwischen .NET Framework und .NET Core, aber der größte Teil des Codes für Windows Forms und WPF-Bereiche wurde unverändert auf Core portiert. Wenn Sie Komponenten wie WCF-Client, Codezugriffssicherheit, Anwendungsdomänen, Interop und Remoting verwendet haben, müssen Sie den Code umgestalten, wenn Sie auf .NET Core wechseln möchten.
Ein weiterer Punkt, den Sie beachten sollten: Die Standardausgabepfade in .NET Core unterscheiden sich von denen in .NET Framework. Wenn Sie also in Ihrem Code einige Annahmen zur Datei- / Ordnerstruktur der ausgeführten App treffen, schlägt diese wahrscheinlich zur Laufzeit fehl.
Außerdem gibt es Änderungen bei der Konfiguration der .NET-Funktionen. .NET Core anstelle der Datei
machine.config Datei
<something>.runtimeconfig.json , die mit einer Anwendung
<something>.runtimeconfig.json und denselben allgemeinen Zweck und ähnliche Informationen hat. Einige Konfigurationen wie
system.net ,
system.net oder
system.servicemodel werden nicht unterstützt, sodass eine App-Konfigurationsdatei nicht geladen werden kann, wenn sie einen dieser Abschnitte enthält. Diese Änderung wirkt sich auf Szenarien der System-,
System.Diagnostics und des WCF-Clients aus, die zuvor häufig mit XML-Konfiguration konfiguriert wurden. In .NET Core müssen Sie sie stattdessen in Code konfigurieren.
appSettings Verhalten ohne Neukompilierung ändern
appSettings und WCF-Typen mit Werten
appSettings die aus einer
Microsoft.Extensions.Configuration Quelle oder aus
appSettings .
Weitere Informationen zu Unterschieden zwischen .NET Core und .NET Framework finden Sie in der
Dokumentation .
Erste Schritte
Sehen Sie sich diese kurzen Video-Tutorials an:
Portierung von .NET Framework nach .NET Core
Führen Sie zunächst den
Portability Analyzer aus und aktualisieren Sie gegebenenfalls Ihren Code, um eine 100% ige Kompatibilität mit .NET Core zu erhalten. Hier finden Sie
Anweisungen zur Verwendung des Portability Analyzer . Wir empfehlen, eine Quellcodeverwaltung zu verwenden oder Ihren Code zu sichern, bevor Sie Änderungen an Ihrer Anwendung vornehmen, falls das Refactoring nicht wie gewünscht verläuft und Sie sich dazu entschließ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 ein Tool ausprobieren, das wir zur Automatisierung der Konvertierung Ihrer .NET Framework-Projekte in .NET Core erstellt haben -
try-convert .
Beachten Sie, dass dieses Tool nur ein Ausgangspunkt für Ihre Reise zu .NET Core ist. Es 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 konvertiert, müssen Sie manuell portieren. Keine Sorge, wir haben viele Anleitungen dazu (am Ende dieses Abschnitts).
Das Tool "try-convert" versucht, Ihre Projektdateien im alten Stil auf das neue SDK-Format zu migrieren und anwendbare Projekte erneut auf .NET Core auszurichten. Für Ihre Bibliotheken überlassen wir es Ihnen, einen Anruf bezüglich der Plattform zu tätigen: Wetter, auf das Sie .NET Core oder .NET Standard abzielen möchten. Sie können es in Ihrer 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 Ausrichtung auf .NET Standard profitieren:
<TargetFramework>netstandard2.1</TargetFramework>
Damit können sie von Anrufern verwendet werden, die auf viele verschiedene .NET-Plattformen abzielen. Wenn eine Bibliothek eine Funktion verwendet, für die .NET Core erforderlich ist (z. B. Windows-APIs für die Desktop-Benutzeroberfläche), kann die Bibliothek .NET Core als Ziel verwenden:
<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 Materialien zum manuellen Portieren Ihrer Anwendung, falls das Try-Convert-Tool bei Ihnen nicht funktioniert hat.
VideosDokumentation