Microsoft Windows App SDK 1.0 Stable veröffentlicht, zum Download verfügbar (Versionshinweise)

Nach mehreren Preview-Builds hat Microsoft gerade das Windows App SDK 1.0.0 Stable veröffentlicht, ein Toolkit, mit dem Desktop-App-Entwickler Apps mit einer modernen Windows-Benutzeroberfläche, APIs und Plattformfunktionen erstellen können.

In dieser Version hat Microsoft mehrere neue Funktionen von Windows App SDK 0.8 hinzugefügt und Probleme von 1.0 Preview-Versionen stabilisiert.

[lwptoc title=“WindowsAppSDK 1.0 Stable“ width=“30%“ float=“right“]

WindowsUI 3

WinUI 3 ist das native User Experience (UX)-Framework für das Windows App SDK.

Neue Funktionen und Aktualisierungen:

• Microsoft hat neue Steuerelemente (PipsPager, Expander, BreadcrumbBar) hinzugefügt und vorhandene Steuerelemente aktualisiert, um die neuesten Windows-Stile widerzuspiegeln WindowsUI 2.6.
• Das MSIX-Packaging für einzelne Projekte wird in WinUI unterstützt, indem eine neue Anwendung mithilfe der Vorlage „Blank App, Packaged…“ erstellt wird.
• Microsoft unterstützt jetzt die Bereitstellung von WinUI 3-Apps ohne MSIX-Paketierung auf Windows-Versionen 1809 und höher. Bitte ansehen Erstellen Sie eine unverpackte WinUI 3-Desktop-App für weitere Informationen.
• WinUI 3-Projekte können jetzt ihre Zielversion auf Windows 10, Version 1809, festlegen. Zuvor konnten sie nur auf Version 1903 festgelegt werden.
• In-App-Symbolleiste, Hot Reload und Live Visual Tree für gepackte WinUI-Apps werden in Visual Studio 2022 Preview 5 und GA unterstützt.

Wichtige Einschränkungen:

• Bekannte Probleme für sowohl verpackte als auch unverpackte WinUI-Anwendungen:
  • Laufzeitfehler in C++-Apps, die auf eine C++-Windows-Laufzeitkomponente verweisen: Um das Problem zu lösen, fügen Sie das folgende Ziel am Ende der .vcxproj-Datei der Windows-Runtime-Komponente hinzu:

    XMLKopieren

    <Target Name="GetPriIndexName">
    <PropertyGroup>
        <!-- Winmd library targets use the default root namespace of the project for the App package name -->
        <PriIndexName Condition="'$(RootNamespace)' != ''">$(RootNamespace)</PriIndexName>
        <!-- If RootNamespace is empty fall back to TargetName -->
        <PriIndexName Condition="$(PriIndexName) == ''">$(TargetName)</PriIndexName>
    </PropertyGroup>
    </Target>
    

• Bekannte Probleme für WinUI-Anwendungen mit Einzelprojekt-MSIX (Leere App, gepackte Vorlage):
  • Fehlende Menüoption „Packen und veröffentlichen“, bis Sie Visual Studio neu starten: Beim Erstellen einer neuen App mit Einzelprojekt-MSIX in Visual Studio 2019 und Visual Studio 2022 mithilfe der Projektvorlage „Leere App, verpackt (WinUI 3 in Desktop)“ wird der Befehl zum Veröffentlichen des Projekts erst im Menü angezeigt, wenn Sie es schließen und öffnen Sie Visual Studio erneut.
  • Die AC#-App mit Einzelprojekt-MSIX lässt sich nicht kompilieren, ohne dass die optionale Komponente „C++ (v14x) Universal Windows Platform Tools“ installiert ist. Aussicht Entwicklertools installieren für weitere Informationen.
  • Potenzieller Laufzeitfehler in einer App mit Einzelprojekt-MSIX, die Typen verwendet, die in einer referenzierten Windows-Runtime-Komponente definiert sind: Um das Problem zu lösen, fügen Sie es manuell hinzu aktivierbare Klasseneinträge in die appxmanifest.xml.
    • Der erwartete Fehler in C#-Anwendungen ist „COMException: Klasse nicht registriert (0x80040154 (REGDB_E_CLASSNOTREG)).
    • Der erwartete Fehler in C++/WinRT-Anwendungen lautet „winrt::hresult_class_not_registered“.
• Bekannte Probleme für WinUI-Anwendungen ohne MSIX-Paketierung (unverpackte Apps):
  • Einige APIs erfordern eine Paketidentität und werden in nicht gepackten Apps nicht unterstützt, wie z. B.:
    • Anwendungsdaten
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • APIInformationen (unter Windows 10 nicht unterstützt)
    • Paket.Aktuell
    • Jede API in der Windows.ApplicationModel.Resources Namensraum
    • Jede API in der Microsoft.Windows.ApplicationModel.Resources Namensraum
• Bekannte Probleme für Packen und Bereitstellen von WinUI-Anwendungen:
  • Das Package Der Befehl wird in WinUI-Apps mit Einzelprojekt-MSIX (leere App, gepackte Vorlage) nicht unterstützt. Verwenden Sie stattdessen die Package & Publish Befehl zum Erstellen eines MSIX-Pakets.
  • So erstellen Sie ein NuGet-Paket aus einer C#-Klassenbibliothek mit der Pack Befehl, stellen Sie sicher, dass aktiv Configuration is Release.
  • Das Pack Der Befehl wird in C++-Windows-Runtime-Komponenten zum Erstellen eines NuGet-Pakets nicht unterstützt.

Fensterung

Das Windows App SDK bietet eine AppWindow -Klasse, die die vorherige benutzerfreundliche Windows.UI.WindowManagement.AppWindow-Vorschauklasse weiterentwickelt und für alle Windows-Apps verfügbar macht, einschließlich Win32, WPF und WinForms.

Neue Funktionen

• AppWindow ist eine High-Level-Windowing-API, die benutzerfreundliche Windowing-Szenarien ermöglicht, die sich gut in die Windows-Benutzererfahrung und in andere Apps integrieren lassen. Stellt eine Abstraktion auf hoher Ebene eines vom System verwalteten 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 sie auf dem Bildschirm verschieben. Für Entwickler, die mit Win32 vertraut sind, kann das AppWindow als Abstraktion auf hoher Ebene des HWND angesehen werden.
• Anzeigebereich stellt eine High-Level-Abstraktion eines HMONITOR dar und folgt den gleichen Prinzipien wie AppWindow.
• DisplayAreaWatcher ermöglicht es einem Entwickler, Änderungen in der Anzeigetopologie zu beobachten und derzeit im System definierte Anzeigebereiche aufzuzählen.

zufuhr

Dies sind die Eingabe-APIs, die WinUI unterstützen und eine API-Oberfläche auf niedrigerer Ebene für Entwickler bereitstellen, um erweiterte Eingabeinteraktionen zu erreichen.

Neue Funktionen

• Zeiger-APIs: ZeigerPunkt, PointerPointProperties und PointEventArgs um das Abrufen von Zeigerereignisinformationen mit XAML-Eingabe-APIs zu unterstützen.
• InputPointerSource-API: Stellt ein Objekt dar, das zum Melden von Zeigereingaben registriert ist, und stellt Zeigercursor- und Eingabeereignisbehandlung für die SwapChainPanel-API von XAML bereit.
• Cursor-API: Ermöglicht Entwicklern, die Cursor-Bitmap zu ändern.
• GestureRecognizer-API: Ermöglicht Entwicklern, bestimmte Gesten wie Ziehen, Halten und Klicken zu erkennen, wenn ihnen Zeigerinformationen gegeben werden.

Wichtige Einschränkungen

• Alle ZeigerPunkt Statische Werksfunktionen wurden entfernt: HolenCurrentPoint, GetCurrentPointTransformed, GetZwischenpunkte und GetIntermediatePointsTransformed.
• Das Windows App SDK unterstützt das Abrufen nicht ZeigerPunkt Objekte mit Zeiger-IDs. Stattdessen können Sie die verwenden ZeigerPunkt Mitgliedsfunktion GetTransformedPoint um eine transformierte Version einer bestehenden abzurufen ZeigerPunkt Objekt. Für Zwischenpunkte können Sie die verwenden PointEventArgs Mitgliedsfunktionen GetZwischenpunkte machen GetTransformedIntermediatePoints.
• Direkte Nutzung der Plattform-SDK-API Windows.UI.Core.CoreDragOperation funktioniert nicht mit WinUI-Anwendungen.
• ZeigerPunkt immobilien RawPosition machen KontaktRectRaw wurden entfernt, weil sie sich auf nicht vorhergesagte Werte bezogen, die mit den normalen Werten im Betriebssystem identisch waren. Benutzen Position machen KontaktRect stattdessen. Die Zeigervorhersage wird jetzt mit behandelt Microsoft.UI.Input.PointerPredictor API-Objekt.

App-Lebenszyklus

Die meisten App-Lebenszyklusfeatures sind bereits in der UWP-Plattform vorhanden und wurden in das Windows App SDK zur Verwendung durch Desktop-App-Typen integriert, insbesondere nicht gepackte 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 auf der UWP-Plattform selbst entsprechende Features gibt.

Nicht-UWP-Apps können auch in MSIX-Pakete verpackt werden. Diese Apps können zwar einige der App-Lebenszyklusfeatures des Windows App SDK verwenden, sie müssen jedoch den Manifestansatz verwenden, sofern dieser verfügbar ist. Beispielsweise können sie das Windows App SDK nicht verwenden RegistrierenForXXXAktivierung APIs und müssen sich stattdessen über das Manifest für die Rich-Aktivierung registrieren.

Alle Einschränkungen für gepackte Apps gelten auch für gepackte WinUI-Apps, und es gibt zusätzliche Überlegungen, wie unten beschrieben.

Wichtige Überlegungen:

• Rich-Aktivierung: GetActivatedEventArgs
  • Unverpackte Anwendungen: Voll nutzbar.
  • Gepackte Anwendungen: Nutzbar, aber auch diese Apps können die Plattform nutzen GetActivatedEventArgs. Beachten Sie, dass die Plattform definiert Windows.ApplicationModel.AppInstance wohingegen das Windows App SDK definiert Microsoft.Windows.AppLifecycle.AppInstance. Und während UWP-Apps die verwenden können ActivatedEventArgs Klassen, wie z FileActivatedEventArgs machen LaunchActivatedEventArgsmüssen Apps, die das AppLifecycle-Feature des Windows App SDK verwenden, die Schnittstellen und nicht die Klassen verwenden (z. B. IFileActivatedEventArgs, ILaunchActivatedEventArgs, und so weiter).
  • WinUi-Apps: App.OnLaunched von WinUI erhält a Microsoft.UI.Xaml.LaunchActivatedEventArgs, während die Plattform GetActivatedEventArgs gibt a zurück Windows.ApplicationModel.IActivatedEventArgs, und das WindowsAppSDK GetActivatedEventArgs gibt a zurück Microsoft.Windows.AppLifecycle.AppActivationArguments Objekt, das eine Plattform darstellen kann LaunchActivatedEventArgs.
  • Weitere Informationen finden Sie unter Reichhaltige Aktivierung.
• Für die Rich-Aktivierung registrieren/abmelden
  • Unverpackte Anwendungen: Voll nutzbar.
  • Gepackte Anwendungen: Nicht verwendbar Verwenden Sie stattdessen das MSIX-Manifest der App.
  • Weitere Informationen finden Sie unter Reichhaltige Aktivierung.
• Single/Multi-Instanziierung
  • Unverpackte Anwendungen: Voll nutzbar.
  • Gepackte Anwendungen: Voll nutzbar.
  • WinUI-Apps: Wenn eine App andere Instanzen erkennen und eine Aktivierung umleiten möchte, muss sie dies so früh wie möglich und vor dem Initialisieren von Fenstern usw. tun. Um dies zu aktivieren, muss die App DISABLE_XAML_GENERATED_MAIN definieren und ein benutzerdefiniertes Main (C#) oder schreiben WinMain (C++), wo es die Erkennung und Umleitung durchführen kann.
  • 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, sodass Sie stattdessen den Umleitungsaufruf in einen anderen Thread verschieben müssen, um sicherzustellen, dass Sie die STA nicht blockieren.
  • Weitere Informationen finden Sie unter App-Instanziierung.
• Power/State-Benachrichtigungen
  • Unverpackte Anwendungen: Voll nutzbar.
  • Gepackte Anwendungen: Voll nutzbar.
  • Weitere Informationen finden Sie unter Power-Management.

Bekanntes Problem:

• Dateitypzuordnungen codieren %1 fälschlicherweise als %251, wenn die Befehlszeilenvorlage des Verb-Handlers festgelegt wird, was unverpackte Win32-Apps zum Absturz bringt. Als Teilumgehung können Sie den Registrierungswert stattdessen manuell auf %1 ändern. Wenn der Zieldateipfad ein Leerzeichen enthält, schlägt er trotzdem fehl und es gibt keine Problemumgehung für dieses Szenario.
• Diese Single/Multi-Instanziierungsfehler werden in einem kommenden Wartungspatch behoben:
  • Die AppInstance-Umleitung funktioniert nicht, wenn sie für x86 kompiliert wurde
  • Das Registrieren eines Schlüssels, das Aufheben der Registrierung und das erneute Registrieren führt zum Absturz der App

WriteCore

DWriteCore ist die Windows App SDK-Implementierung von DirectWrite, die DirectX-API für qualitativ hochwertiges Text-Rendering, auflösungsunabhängige Outline-Schriftarten und vollständige Unterstützung von Unicode-Text und -Layout. DWriteCore ist eine Form von DirectWrite, die auf Windows-Versionen bis hinunter zu Windows 10, Version 1809 (10.0; Build 17763) ausgeführt wird und Ihnen die Tür zur plattformübergreifenden Verwendung öffnet.

Eigenschaften DWriteCore enthält mit wenigen Ausnahmen alle Funktionen von DirectWrite.

Wichtige Einschränkungen

• DWriteCore enthält nicht die folgenden DirectWrite-Funktionen:
  • Schriftarten pro Sitzung
  • Endbenutzerdefinierte Zeichenschriftarten (EUDC).
  • Font-Streaming-APIs
• Die Low-Level-Rendering-API-Unterstützung ist teilweise.
• DWriteCore interoperiert nicht mit Direct2D, aber Sie können es verwenden IDWriteGlyphRunAnalysis machen IDWriteBitmapRenderTarget.

MRT-Kern

MRT Core ist eine optimierte Version des modernen Windows Ressourcenmanagementsystem die als Teil des Windows App SDK verteilt wird.

Wichtige Einschränkungen

• In .NET-Projekten werden Ressourcendateien, die per Copy-Paste in den Projektordner eingefügt wurden, nicht auf F5 indiziert, wenn die App bereits erstellt wurde. Erstellen Sie als Problemumgehung die App neu. Sehen Ausgabe 1503 for more info
• Wenn in .NET-Projekten eine Ressourcendatei mithilfe der Benutzeroberfläche von Visual Studio zum Projekt hinzugefügt wird, werden die Dateien möglicherweise nicht standardmäßig indiziert. Sehen Ausgabe 1786 Für mehr Information. Um dieses Problem zu umgehen, entfernen Sie bitte die folgenden Einträge in der CSPROJ-Datei:

  XMLKopieren

  <ItemGroup>
      <Content Remove="<image file name>" />
  </ItemGroup>
  <ItemGroup>
      <PRIResource Remove="<resw file name>" />
  </ItemGroup>
  

• Bei unverpackten C++-WinUI-Apps wird der Ressourcen-URI nicht korrekt erstellt. Um dieses Problem zu umgehen, fügen Sie Folgendes in vcxproj hinzu:

  XMLKopieren

  <!-- Add the following after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> -->
  
  <PropertyGroup>
      <AppxPriInitialPath></AppxPriInitialPath>   
  </PropertyGroup>
  

Einsatz

Neue Funktionen und Aktualisierungen

• Sie können das Windows App SDK automatisch über die initialisieren WindowsPackageType project -Eigenschaft, um die Windows App SDK-Laufzeit zu laden und die Windows App SDK-APIs aufzurufen. Sehen Erstellen Sie eine WinUI 3-App für weitere Instruktionen.
• Nicht gepackte Apps können das Windows App SDK bereitstellen, indem sie in das eigenständige Windows App SDK integriert werden .exe installer in Ihr vorhandenes MSI- oder Setup-Programm. Weitere Informationen finden Sie unter Windows App SDK-Bereitstellungsleitfaden für nicht gepackte Apps.
• Unverpackte .NET-Apps können auch den .NET-Wrapper für die verwenden Bootstrapper-API um zur Laufzeit dynamisch eine Abhängigkeit vom Windows App SDK-Frameworkpaket zu übernehmen. Weitere Informationen zum .NET-Wrapper finden Sie unter .NET-Wrapper-Bibliothek.
• Gepackte Apps können die Bereitstellungs-API verwenden, um zu überprüfen und sicherzustellen, dass alle erforderlichen Pakete auf dem Computer installiert sind. Weitere Informationen zur Funktionsweise der Bereitstellungs-API finden Sie unter Bereitstellungsleitfaden für gepackte Apps.

Wichtige Einschränkungen

• Der .NET-Wrapper für die Bootstrapper-API ist nur für die Verwendung durch unverpackte .NET-Anwendungen vorgesehen, um den Zugriff auf das Windows App SDK zu vereinfachen.
• Nur MSIX-gepackte Apps, die voll vertrauenswürdig sind oder die haben Paketverwaltung mit eingeschränkter Berechtigung haben die Berechtigung, die Bereitstellungs-API zu verwenden, um die Haupt- und Singleton-Paketabhängigkeiten zu installieren. Die Unterstützung für teilweise vertrauenswürdige gepackte Apps wird in späteren Versionen verfügbar sein.
• Wenn F5 eine x86-App testet, die die DeploymentManager.Initialize -Methode auf einem x64-System sicherstellen, dass das x64-Framework zuerst installiert wird, indem Sie die WindowsAppRuntimeInstall.exe. Andernfalls werden Sie auf a stoßen NICHT GEFUNDEN Fehler, der darauf zurückzuführen ist, dass Visual Studio das x64-Framework nicht bereitstellt, was normalerweise durch Store-Bereitstellung oder Querladen auftritt.

Andere Einschränkungen und bekannte Probleme

• Keine Unterstützung für jede CPU-Build-Konfiguration: Wann Hinzufügen des Windows App SDK zu einer vorhandenen .NET-Anwendung oder -Komponente, die unterstützt Beliebige CPU, müssen Sie die gewünschte Architektur angeben: x86, x64 or arm64.
• Upgrade von .NET 5 auf .NET 6: Beim Upgrade in der Visual Studio-Benutzeroberfläche treten möglicherweise Buildfehler auf. Als Problemumgehung aktualisieren Sie das TargetFrameworkPackage Ihrer Projektdatei manuell wie folgt:

  XMLKopieren

      <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework> 
  

• Die C#-Einzelprojekt-MSIX-App wird nicht kompiliert, wenn die C++-UWP-Tools nicht installiert sind. Wenn Sie ein C#-Einzelprojekt-MSIX-Projekt haben, müssen Sie die C++ (v14x) Universelle Windows-Plattformtools optionale Komponente.
• Die nachfolgende Sprache VSIX kann nicht in Visual Studio 2019 installiert werden, wenn mehrere Versionen von Visual Studio 2019 installiert sind. Wenn Sie mehrere Versionen von Visual Studio 2019 installiert haben (z. B. Release und Preview) und dann das Windows App SDK VSIX für beide C++ installieren machen C#, die zweite Installation schlägt fehl. Um das Problem zu lösen, deinstallieren Sie die Einzelprojekt-MSIX-Verpackungstools für Visual Studio 2019 nach dem ersten Sprach-VSIX. Aussicht diese Rückmeldung für weitere Informationen zu diesem Problem.
• Wenn du möchtest co_await auf die DispatcherQueue.TryEnqueue Methode, dann verwenden Sie die Lebenslauf_Vordergrund Helferfunktion in der Windows-Implementierungsbibliothek (WIL):
  1. Fügen Sie eine Referenz hinzu zu Microsoft.Windows.ImplementationLibrary NuGet-Paket.
  2. Fügen Sie #include <wil/cppwinrt_helpers.h> -Anweisung zu Ihrer Codedatei.
  3. Verwenden Sie die wil::resume_foreground(your_dispatcher); zu co_await das Ergebnis.

Lesen Sie mehr und finden Sie die Download-Links bei Microsoft hier.