Nach mehreren Vorschau-Builds, Microsoft hat gerade das Windows App SDK 1.0.0 Stable veröffentlicht, ein Toolkit, das es Entwicklern von Desktop-Apps ermöglicht, Apps mit einer modernen Windows-Benutzeroberfläche, APIs und Plattformfunktionen zu erstellen.
In dieser Version fügte Microsoft hinzu mehrere neue Funktionen von Windows App SDK 0.8 und stabilisierte Probleme von 1.0 Vorschauversionen.
WinUI 3
WinUI 3 ist das native User Experience (UX) Framework für Windows App SDK.
Neue Funktionen und Updates:
Microsoft hat neue Steuerelemente (PipsPager, Expander, BreadcrumbBar) hinzugefügt und vorhandene Steuerelemente aktualisiert, um die neuesten Windows-Stile von WinUI 2.6.Single-Projekt MSIX-Paketierung wird unterstützt ord in WinUI durch Erstellen einer neuen Anwendung mit der Vorlage „Blank App, Packaged…“. Microsoft unterstützt jetzt die Bereitstellung von WinUI 3-Apps ohne MSIX-Paket unter Windows-Versionen 1809 und höher. Bitte lesen Sie Ein WinUI 3 ohne Paket erstellen Desktop-App für zusätzliche Informationen.WinUI 3-Projekte können ihre Zielversion jetzt auf Windows 10, Version 1809, festlegen. Bisher konnten sie nur auf Version 1903 festgelegt werden.In-App-Symbolleiste, Hot Reload und Live Visual Tree for WinUI-verpackte Apps werden in Visual Studio 2022 Preview 5 und GA unterstützt.
Wichtige Einschränkungen:
Bekannte Probleme für sowohl verpackte als auch nicht verpackte WinUI-Anwendungen:Bekannte Probleme für WinUI-Anwendungen mit Einzelprojekt-MSIX (leere App, gepackte Vorlage):Missing Package & Publish-Menüelement bis Sie Visual Studio neu starten: Beim Erstellen einer neuen App mit Einzelprojekt-MSIX in beiden Visual Studio 2019 und Visual Studio 2022 unter Verwendung der Projektvorlage Leere App, verpackt (WinUI 3 in Desktop) wird der Befehl zum Veröffentlichen des Projekts nicht in der Datei angezeigt nu, bis Sie Visual Studio schließen und erneut öffnen. Eine C#-App mit Einzelprojekt-MSIX wird nicht kompiliert, wenn die optionale Komponente „C++ (v14x) Universal Windows Platform Tools“ installiert ist. Entwicklertools installieren für zusätzliche Informationen.Möglicher Laufzeitfehler in einer App mit Einzelprojekt-MSIX, die Typen verwendet, die in einer referenzierten Windows-Laufzeitkomponente definiert sind: Um das Problem zu beheben, fügen Sie aktivierbare Klasseneinträge zu appxmanifest.xml.Das erwartete Fehler in C#-Anwendungen ist „COMException: Klasse nicht registriert (0x80040154 (REGDB_E_CLASSNOTREG)). Der erwartete Fehler in C++/WinRT-Anwendungen ist „winrt::hresult_class_not_registered“. Bekannte Probleme für WinUI-Anwendungen ohne MSIX-Paket (nicht gepackte Apps): Einige APIs erfordern eine Paketidentität und werden in nicht gepackten Apps nicht unterstützt, z. B.: Bekannte Probleme beim Verpacken und Bereitstellen von WinUI-Anwendungen: Das Paket Befehl wird in WinUI-Apps mit Einzelprojekt-MSIX (leere App, verpackte Vorlage) nicht unterstützt. Verwenden Sie stattdessen den Befehl Package & Publish , um ein MSIX-Paket zu erstellen. Um ein NuGet-Paket aus einer C#-Klassenbibliothek mit dem Befehl Pack zu erstellen, stellen Sie sicher, dass die aktive Konfiguration Release ist NuGet-Paket.
Windowing
Das Windows App SDK bietet ein AppWindow Klasse, die die vorherige benutzerfreundliche Windows.UI.WindowManagement.AppWindow-Vorschauklasse weiterentwickelt und für alle Windows-Apps, einschließlich Win32, verfügbar macht , WPF und WinForms.
Neue Funktionen
AppWindow ist eine High-Level-Windowsing-API, die benutzerfreundliche Windowing-Szenarien ermöglicht, die sich gut in den Windows-Benutzer integrieren lassen Erfahrung und mit anderen Apps. Stellt eine abstrakte Abstraktion eines systemverwalteten Containers des Inhalts einer App dar. Dies ist der Container, in dem Ihre Inhalte gehostet werden, und stellt die Entität dar, mit der Benutzer interagieren, wenn sie die Größe Ihrer App ändern und auf dem Bildschirm verschieben. Für Entwickler, die mit Win32 vertraut sind, kann das AppWindow als eine abstrakte Abstraktion des HWND auf hoher Ebene angesehen werden.DisplayArea stellt eine abstrakte Abstraktion eines HMONITORs auf hoher Ebene dar und folgt den gleichen Prinzipien wie AppWindow.DisplayAreaWatcher ermöglicht einem Entwickler, Änderungen in der Anzeigetopologie zu beobachten und aufzuzählen DisplayAreas, die derzeit im System definiert sind.
Eingabe
Dies sind die Eingabe-APIs, die WinUI unterstützen und Entwicklern eine API-Oberfläche auf niedrigerer Ebene bieten, um erweiterte Eingabeinteraktionen zu erzielen.
Neue Funktionen
Wichtige Einschränkungen
Alle PointerPoint statische Factory-Funktionen wurden entfernt: GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints und GetIntermediatePointsTransformed. Das Windows App SDK funktioniert nicht Das Abrufen von PointerPoint Objekten mit Zeiger-IDs wird nicht unterstützt. Stattdessen können Sie die Memberfunktion PointerPoint GetTransformedPoint verwenden, um eine transformierte Version eines vorhandenen PointerPoint Objekts abzurufen. Für Zwischenpunkte können Sie die PointerEventArgs Mitgliedsfunktionen GetIntermediatePoints und GetTransformedIntermediatePoints.Direkte Nutzung der Plattform-SDK-API Windows.UI.Core.CoreDragOperation funktioniert nicht mit WinUI-Anwendungen.PointerPoint Eigenschaften RawPosition und ContactRectRaw wurden entfernt, da sie sich auf nicht vorhergesagte Werte bezogen, die den normalen Werten in entsprachen das Betriebssystem. Verwenden Sie Position und ContactRect stattdessen. Die Zeigervorhersage wird jetzt mit dem Microsoft.UI.Input.PointerPredictor API-Objekt verarbeitet.
App Lifecycle
Die meisten App Lifecycle-Features sind bereits in der UWP-Plattform vorhanden und wurden in das Windows App SDK aufgenommen, um von Desktop-App-Typen verwendet zu werden, insbesondere von nicht gepackten Konsolen-Apps, Win32-Apps, Windows Forms-Apps und WPF-Apps. Die Windows App SDK-Implementierung dieser Features kann nicht in UWP-Apps verwendet werden, da es entsprechende Features in der UWP-Plattform selbst gibt.
Wichtig
Wenn Sie an einer UWP-App arbeiten, siehe den UWP-Migrationsleitfaden, um mehr über die Migration Ihrer App zum Windows App SDK zu erfahren.
Nicht-UWP-Apps können auch in MSIX-Pakete verpackt werden. Diese Apps können zwar einige der Windows App SDK App Lifecycle-Features verwenden, müssen jedoch den Manifest-Ansatz verwenden, sofern dieser verfügbar ist. Sie können beispielsweise die APIs des Windows App SDK RegisterForXXXActivation nicht verwenden und müssen sich stattdessen über das Manifest für die Rich-Aktivierung registrieren.
Alle Einschränkungen für verpackte Apps gelten auch für WinUI-Apps, die verpackt sind, und es gibt zusätzliche Überlegungen, wie unten beschrieben.
Wichtige Überlegungen:
Rich-Aktivierung: GetActivatedEventArgsRegistrieren/Unregistrieren für Rich-AktivierungUnpackaged apps: Fully usable.Packaged Apps: Nicht verwendbar Verwenden Sie stattdessen das MSIX-Manifest der App. Weitere Informationen finden Sie unter Rich-Aktivierung.Single/Multi-instancingUnpackaged apps: Vollständig verwendbar.Packaged apps: Vollständig verwendbar.WinUI apps: Wenn eine App andere Instanzen erkennen möchte Um dies zu ermöglichen, muss die App DISABLE_XAML_GENERATED_MAIN definieren und ein benutzerdefiniertes Main (C#) oder WinMain (C++) schreiben, wo es möglich ist die Erkennung und Umleitung.RedirectActivationToAsync ist ein asynchroner Aufruf, und Sie sollten nicht auf einen asynchronen Aufruf warten, wenn Ihre App in einer STA ausgeführt wird. Für Windows Forms-und C#-WinUI-Apps können Sie Main bei Bedarf als asynchron deklarieren. Für C++-WinUI-und C#-WPF-Apps können Sie Main nicht als asynchron deklarieren. Stattdessen müssen Sie den Umleitungsaufruf in einen anderen Thread verschieben, um sicherzustellen, dass Sie die STA nicht blockieren. Weitere Informationen finden Sie unter App-Instanzierung.Power/State notificationsUnpackaged apps: Vollständig verwendbar. Gepackte Apps: Vollständig verwendbar. Weitere Informationen finden Sie unter Energieverwaltung.
Bekanntes Problem:
Dateitypzuordnungen codieren %1 fälschlicherweise in %251 beim Festlegen der Befehlszeilenvorlage des Verb-Handlers, wodurch nicht gepacktes Win32 abstürzt Apps. Als teilweise Problemumgehung können Sie stattdessen den Registrierungswert manuell so bearbeiten, dass er %1 ist. Wenn der Zieldateipfad ein Leerzeichen enthält, schlägt es immer noch fehl und es gibt keine Problemumgehung für dieses Szenario. Diese Einzel-/Mehrfachinstanzierungsfehler werden in einem kommenden Wartungspatch behoben: Die AppInstance-Umleitung funktioniert nicht, wenn sie für kompiliert wird x86Das Registrieren eines Schlüssels, das Aufheben der Registrierung und das erneute Registrieren führt zum Absturz der App
DWriteCore
DWriteCore ist die Windows App SDK-Implementierung von DirectWrite, die DirectX-API für hochwertiges Text-Rendering, auflösungsunabhängige Outline-Schriftarten und vollständigen Unicode Text-und Layoutunterstützung. DWriteCore ist eine Form von DirectWrite, die auf Windows-Versionen bis Windows 10, Version 1809 (10.0; Build 17763) ausgeführt wird und Ihnen die Tür zur plattformübergreifenden Verwendung öffnet.
Funktionen DWriteCore enthält mit wenigen Ausnahmen alle Funktionen von DirectWrite.
Wichtige Einschränkungen
DWriteCore enthält nicht die folgenden DirectWrite-Funktionen:Pro-Sitzung fontsEnd-User Defined Character (EUDC)-FontsFont-Streaming-APIsLow-Level-Rendering-API-Unterstützung ist teilweise.DWriteCore interoperiert nicht mit Direct2D, aber Sie können IDWriteGlyphRunAnalysis und IDWriteBitmapRenderTarget.
MRT Core
MRT Core ist eine optimierte Version des modernen Windows Ressourcenverwaltungssystem, das als Teil des Windows App SDK verteilt wird.
Wichtige Einschränkungen
In.NET-Projekten werden Ressourcendateien, die in den Projektordner kopiert und eingefügt werden, nicht mit F5 indiziert, wenn die App bereits erstellt wurde. Erstellen Sie als Workaround die App neu. Weitere Informationen finden Sie unter Problem 1503 Wenn das Projekt die Visual Studio-Benutzeroberfläche verwendet, werden die Dateien möglicherweise nicht standardmäßig indiziert. Weitere Informationen finden Sie unter Ausgabe 1786 . Um dieses Problem zu umgehen, entfernen Sie bitte die folgenden Einträge in der CSPROJ-Datei:
