Freigeben über

Versionshinweise zum stabilen Kanal für das Windows App SDK 1.0

  • Artikel

Der stabile Kanal stellt Releases des Windows App SDK bereit, die für die Verwendung durch Apps in Produktionsumgebungen unterstützt werden. Apps, die die stabile Version des Windows App SDK verwenden, können auch im Microsoft Store veröffentlicht werden.

Wichtige Links:

Release des neuesten stabilen Kanals:

Downloads für das Windows App SDK

Hinweis

Die Windows App SDK Visual Studio Extensions (VSIX) werden nicht mehr als separater Download angeboten. Sie sind auf dem Visual Studio Marketplace innerhalb von Visual Studio erhältlich.

Version 1.0.4

Dies ist ein Wartungsrelease des Windows App SDK, das wichtige Fehlerbehebungen für das Release 1.0 enthält.

Fehlerbehebungen (1.0.4)

  • Ein Problem wurde behoben, das dazu führte, dass AppBars bei Verwendung als Page.TopAppBar oder Page.BottomAppBar nicht auf dem Bildschirm gerendert wurden.
  • Ein Problem wurde behoben, bei dem Apps mit einem Paketnamen mit 12 oder weniger Zeichen, die ein WinUI-Steuerelement aus MUXControls.dll verwenden, sofort abstürzen. Weitere Informationen finden Sie im Issue #6360 auf GitHub.
  • Es wurden Probleme bei der Toucheingabe mit Tastenkombinationen und in anderen Szenarien behoben. Weitere Informationen finden Sie im Issue #6291 auf GitHub.
  • Ein Problem wurde behoben, das zu einem Bereitstellungsfehler bei Apps führte, die als MSIX-Paket oder eigenständig bereitgestellt werden sollten.
  • Ein Problem wurde behoben, das dazu führte, dass Apps während eines Drag-and-Drop-Vorgangs manchmal abstürzten. Weitere Informationen finden Sie im Issue #7002 auf GitHub.

Version 1.0.3

Dies ist ein Wartungsrelease des Windows App SDK, das wichtige Fehlerbehebungen für das Release 1.0 enthält.

Fehlerbehebungen (1.0.3)

  • Ein Problem wurde behoben, das dazu führte, dass C#-Apps mit WebView2 beim Start abstürzten, wenn die C/C++-Runtime (CRT) nicht installiert war.
  • Es wurden Probleme bei der Toucheingabe mit Tastenkombinationen und in anderen Szenarien behoben. Weitere Informationen finden Sie im Issue #6291 auf GitHub.

Hinweis: In einer Wartungsversion fügen wir normalerweise keine Funktionalität hinzu, aber für die WebView2-Korrektur in diesem Release mussten wir auf die neueste Version des WebView2 SDK aktualisieren (von 1020.46 auf 1185.39). Weitere Informationen zu WebView2 1.0.1185.39 finden Sie in den Versionshinweisen für das WebView2 SDK. Weitere Informationen zur WebView2-Runtime finden Sie unter Verteilen Ihrer App und der WebView2-Runtime.

Version 1.0.2

Dies ist ein Wartungsrelease des Windows App SDK, das wichtige Fehlerbehebungen für das Release 1.0 enthält.

Fehlerbehebungen (1.0.2)

  • Es wurde ein Layoutzyklusproblem behoben, das dazu führte, dass eine App abstürzte, wenn bis zum Ende einer ListView gescrollt wurde. Weitere Informationen finden Sie im Issue #6218 auf GitHub.
  • Ein Problem wurde behoben, das dazu führte, dass C#-Apps beim Start abstürzten, wenn die C/C++-Runtime (CRT) nicht installiert war. Die CRT ist jedoch weiterhin für C#-Apps erforderlich, die WebView2 verwenden. Weitere Informationen finden Sie im Issue #2117 auf GitHub.
  • Ein Problem wurde behoben, bei dem Anwendungen mit einem MSIX-Einzelprojektpaket keine .appinstaller-Datei generierten. Weitere Informationen finden Sie im Issue #1821 auf GitHub.
  • Ein Problem wurde behoben, bei dem WinUI-Anwendungen .NET 6 nicht unterstützten dotnet build.

Version 1.0.1

Dies ist ein Wartungsrelease des Windows App SDK, das kritische Fehlerbehebungen und Unterstützung für mehrere Fenster für das Release 1.0 enthält.

Fehlerbehebungen (1.0.1)

  • Ein Problem wurde behoben, das dazu führte, dass MddBootstrapAutoinitializer mit aktivierten ImplicitUsings nicht kompiliert wurde. Weitere Informationen finden Sie im Issue #1686 auf GitHub.
  • Ein Problem wurde behoben, bei dem der Fokus in WebView2 unerwartet verlorenging, was zu Eingabe- und Auswahlproblemen führte. Weitere Informationen finden Sie in den Issue 5615 & Issue 5570 auf GitHub.
  • Ein Problem wurde behoben, das dazu führte, dass die App-interne Symbolleiste in Visual Studio bei Verwendung einer benutzerdefinierten Titelleiste in einer WinUI 3-App nicht anklickbar war.
  • Ein Problem wurde behoben, das dazu führte, dass das Andocklayout bei Verwendung einer benutzerdefinierten Titelleiste in einer WinUI 3-App nicht angezeigt wurde. Weitere Informationen finden Sie in den Issue 6333 & Issue 6246 auf GitHub.
  • Ein Problem wurde behoben, das beim Festlegen der Window.ExtendsContentIntoTitleBar-Eigenschaft eine Ausnahme verursachte, wenn Window.SetTitlebar mit einem UIElement aufgerufen wurde, dessen Ladevorgang noch nicht beendet war.
  • Ein Problem wurde behoben, bei dem MSIX-Einzelprojekt-Apps dotnet build nicht unterstützten.
  • Ein Problem wurde behoben, das dazu führte, dass nicht gepackte Apps nach der Installation einer gepackten App nicht installiert wurden. Weitere Informationen finden Sie im Issue #1871 auf GitHub.
  • Ein Problem wurde behoben, das die Leistung bei Mausziehvorgängen verringerte.
  • Es wurde ein Problem mit einem Absturz beim Aufrufen von „GetWindowIdFromWindow()“ in nicht gepackten Apps behoben. Weitere Informationen finden Sie in der Diskussion #1891 auf GitHub.

Die Einschränkungen und bekannten Probleme für Version 1.0 gelten auch für Version 1.0.1.

Darüber hinaus haben wir für Apps mit benutzerdefinierten Titelleisten in diesem Release Änderungen vorgenommen (und zahlreiche Probleme behoben), einschließlich Korrekturen für das durchsichtige Fenster, das für Drag&Drop-Vorgänge verwendet wird. Es wird empfohlen, die Standardwerte und -verhaltensweisen zu verwenden (probieren Sie sie aus!). Wenn die Titelleiste Ränder verwendete, sodass die Standardschaltflächen für Untertitel interaktiv waren, empfiehlt es sich, den Ziehbereich zu visualisieren, indem Sie den Hintergrund der Titelleiste auf Rot festlegen und dann die Ränder anpassen, um den Ziehbereich auf die Untertitel-Steuerelemente zu erweitern.

Neue Funktionen

Wir haben die Erstellung mehrerer Fenster im selben Thread in WinUI 3-Anwendungen stabilisiert und aktiviert. Weitere Informationen finden Sie im Issue #5918.

Version 1.0

In den folgenden Abschnitten werden neue und aktualisierte Features, Einschränkungen und bekannte Probleme für Version 1.0 beschrieben.

WinUI 3

WinUI 3 ist das native UX-Framework (User Experience) für Windows App SDK. In diesem Release haben wir mehrere neue Features aus Windows App SDK 0.8 sowie stabile Lösungen für Probleme aus 1.0 Preview-Releases hinzugefügt.

Neue Features und Updates:

  • Wir haben neue Steuerelemente (PipsPager, Expander, BreadcrumbBar) hinzugefügt und vorhandene Steuerelemente aktualisiert, um die neuesten Windows-Stile aus WinUI 2.6 widerzuspiegeln.
  • Das Packen von MSIX-Einzelprojektpaketen wird in WinUI durch Erstellen einer neuen Anwendung unter Verwendung der Vorlage „Leere App, gepackt …“ unterstützt.
  • Wir unterstützen jetzt die Bereitstellung von WinUI 3-Apps, die in den Windows-Versionen 1809 und höher nicht gepackt sind. Weitere Informationen finden Sie unter Erstellen Ihres ersten WinUI 3-Projekts (Windows App SDK).
  • WinUI 3-Projekte können jetzt ihre Zielversion auf Windows 10, Version 1809 festlegen. Bisher war 1903 die niedrigste Version, die festgelegt werden konnte.
  • Die App-interne Symbolleiste, Hot Reload & Live Visual Tree für gepackte WinUI-Apps werden in Visual Studio 2022 Preview 5 und GA unterstützt.

Wichtige Einschränkungen:

  • Bekannte Probleme sowohl für gepackte als auch für nicht gepackte WinUI-Anwendungen:

    • Laufzeitfehler in C++- oder C#-Apps, die auf eine C++-Windows-Runtime-Komponente verweisen:

      • Fügen Sie zum Beheben des Problems das folgende Ziel am Ende der .vcxproj-Datei der Windows-Runtime-Komponente hinzu:
      <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>
      • Der erwartete Fehler lautet in etwa: WinRT-Ursprungsfehler – 0x80004005: "Ressource von 'ms-appx:///BlankPage.xaml'. kann nicht gefunden werden“.

  • Bekannte Probleme für WinUI-Anwendungen mit MSIX-Einzelprojektpaket (Vorlage „Leere App, gepackt“):

    • Menüelement für „Paket erstellen & veröffentlichen“ fehlt, bis Sie Visual Studio neu starten: Beim Erstellen einer neuen App mit einem MSIX-Einzelprojektpaket in Visual Studio 2019 und Visual Studio 2022 mithilfe der Projektvorlage „Leere App, gepackt“ (WinUI 3 in Desktop) wird der Befehl zum Veröffentlichen des Projekts erst im Menü angezeigt, wenn Sie Visual Studio schließen und erneut öffnen.
    • Eine C#-App mit einem MSIX-Einzelprojektpaket wird nicht kompiliert, ohne dass die optionale Komponente „C++ (v14x)-Tools für Universelle Windows-Plattform“ installiert ist. Weitere Informationen finden Sie unter Installieren von Tools für das Windows App SDK.
    • Potenzieller Laufzeitfehler in einer App mit einem MSIX-Einzelprojektpaket, das in einer referenzierten Windows-Runtime-Komponente definierte Typen verwendet: Fügen Sie zum Beheben manuell aktivierbare Klasseneinträge zur appxmanifest.xml-Datei hinzu.
      • Der erwartete Fehler in C#-Anwendungen lautet „COMException: Klasse nicht registriert (0x80040154 (REGDB_E_CLASSNOTREG))“.
      • Der erwartete Fehler in C++/WinRT-Anwendungen lautet: „winrt::hresult_class_not_registered“.

  • Bekannte Probleme bei WinUI 3-Apps, die nicht gepackt sind (nicht gepackte Apps):

  • Bekannte Probleme beim Packen und Bereitstellen von WinUI-Anwendungen:

    • Der Befehl Package wird in WinUI-Apps mit MSIX-Einzelprojektpaket (Vorlage „Leere App, gepackt“) 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 Configuration auf Release festgelegt ist.
    • Der Befehl Pack wird in C++ Windows-Runtime-Komponenten zum Erstellen eines NuGet-Pakets nicht unterstützt.

Weitere Informationen sowie die erste Schritte zur Entwicklung mit WinUI finden Sie unter:

Windowing

Das Windows App SDK stellt eine AppWindow-Klasse bereit, 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 Features:

  • AppWindow ist eine allgemeine API für Fensterfunktionen, die benutzerfreundliche Fensterszenarien ermöglicht, die sich gut in die Windows-Benutzeroberfläche und andere Apps integrieren lassen. Stellt eine allgemeine Abstraktion eines vom systemseitig verwalteten Containers des Inhalts einer App dar. Dies ist der Container, in dem Ihre Inhalte gehostet werden, und repräsentiert die Entität, mit der Benutzer*innen interagieren, wenn sie die Größe Ihrer App ändern und Ihre App auf dem Bildschirm verschieben. Entwickler*innen, die mit Win32 vertraut sind, können AppWindow als eine allgemeine Abstraktion von HWND betrachten.
  • DisplayArea stellt eine allgemeine Abstraktion von HMONITOR dar und folgt den gleichen Prinzipien wie AppWindow.
  • DisplayAreaWatcher ermöglicht es Entwickler*innen Änderungen in der Anzeigetopologie zu beobachten und DisplayAreas zu enumerieren, die derzeit im System definiert sind.

Weitere Informationen finden Sie unter Verwalten von App-Fenstern (Windows App SDK).

Eingabe

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

Neue Features:

  • Zeiger-APIs: PointerPoint, PointerPointProperties und PointerEventArgs unterstützen das Abrufen von Zeigerereignisinformationen mit XAML-Eingabe-APIs.
  • InputPointerSource-API: Stellt ein Objekt dar, das zum Melden von Zeigereingabe registriert ist, und stellt die Zeigercursor- und Eingabeereignisbehandlung für die SwapChainPanel-API von XAML bereit.
  • Cursor-API: Ermöglicht Entwickler*innen das Ändern der Cursorbitmap.
  • GestureRecognizer-API: Ermöglicht Entwickler*innen, bestimmte Gesten wie Ziehen, Halten und Klicken zu erkennen, wenn Zeigerinformationen angegeben werden.

Wichtige Einschränkungen:

  • Alle statischen PointerPoint-Factoryfunktionen wurden entfernt: GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints und GetIntermediatePointsTransformed.
  • Das Windows App SDK unterstützt das Abrufen von PointerPoint-Objekten mit Zeiger-IDs nicht. Stattdessen können Sie die PointerPoint-Memberfunktion GetTransformedPoint verwenden, um eine transformierte Version eines vorhandenen PointerPoint-Objekts abzurufen. Für Zwischenpunkte können Sie die PointerEventArgs-Memberfunktionen GetIntermediatePoints und GetTransformedIntermediatePoints verwenden.
  • Die direkte Verwendung der Plattform-SDK-API Windows.UI.Core.CoreDragOperation funktioniert mit WinUI-Anwendungen nicht.
  • Die PointerPoint-Eigenschaften RawPosition und ContactRectRaw wurden entfernt, da sie auf nicht vorhergesagte Werte verwiesen, die den normalen Werten im Betriebssystem entsprachen. Verwenden Sie stattdessen Position und ContactRect. Die Zeigervorhersage wird jetzt mit dem API-Objekt Microsoft.UI.Input.PointerPredictor verarbeitet.

App-Lebenszyklus

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

Wichtig

Wenn Sie an einer UWP-App arbeiten, lesen Sie Migrieren von UWP zum Windows App SDK.

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

Alle Einschränkungen für gepackte Apps gelten auch für WinUI-Apps, die gepackt sind, und es müssen einige zusätzliche Aspekte bedacht werden, wie unten beschrieben.

Wichtige Überlegungen:

  • Umfassende Aktivierung: GetActivatedEventArgs

  • Registrieren/Aufheben der Registrierung für die umfassende Aktivierung

  • Einzel-/Mehrfachinstanziierung

    • Nicht gepackte Apps: Vollständig verwendbar.
    • Gepackte Apps: Vollständig verwendbar.
    • WinUI-Apps: Wenn eine App andere Instanzen erkennen und eine Aktivierung umleiten soll, muss sie dies so früh wie möglich und vor der Initialisierung von Fenstern usw. tun. Um dies zu ermöglichen, muss die App DISABLE_XAML_GENERATED_MAIN definieren und eine benutzerdefinierte Main (C#) oder WinMain (C++) schreiben, in der sie die Erkennung und Umleitung durchführen kann.
    • RedirectActivationToAsync ist ein asynchroner Aufruf, und auf einen asynchronen Aufruf sollte nicht gewartet werden, wenn Ihre App in einem STA ausgeführt wird. Bei Windows Forms- und C#-WinUI-Apps können Sie Main bei Bedarf als asynchron deklarieren. Bei C++-WinUI- und C#-WPF-Apps können Sie Main nicht als asynchron deklarieren. Stattdessen müssen Sie den Umleitungsaufruf an einen anderen Thread verschieben, um sicherzustellen, dass Sie das STA nicht blockieren.
    • Weitere Informationen finden Sie unter App-Instanziierung mit der App-Lebenszyklus-API.

  • Benachrichtigungen zu Energieversorgung/Zustand

Bekanntes Problem:

  • Dateitypzuordnungen codieren „%1“ fälschlicherweise als „%251“, wenn die Befehlszeilenvorlage des Verb-Handlers festgelegt wird, wodurch ungepackte Win32-Apps abstürzen. Sie können das Problem teilweise umgehen, indem Sie den Registrierungswert manuell auf „%1“ festlegen. Wenn der Zieldateipfad ein Leerzeichen enthält, tritt weiterhin ein Fehler auf, und für dieses Szenario gibt es keine Problemumgehung.
  • Diese Fehler bei Einzel-/Mehrfachinstanziierung werden in einem zukünftigen Wartungspatch behoben:
    • AppInstance-Umleitung funktioniert bei Kompilierung für x86 nicht
    • Wenn Sie einen Schlüssel registrieren, die Registrierung aufheben und ihn erneut registrieren, stürzt die App ab.

DWriteCore

DWriteCore ist die Windows App SDK-Implementierung von DirectWrite, die DirectX-API für hochwertiges Textrendering, auflösungsunabhängige Vektorschriftarten und vollständige Unicode-Text- und Layoutunterstützung. DWriteCore ist eine Form von DirectWrite, die auf Windows-Versionen bis hinunter zu Windows 10, Version 1809 (10.0; Build 17763), ausgeführt werden kann und Ihnen die Möglichkeit der plattformübergreifenden Nutzung eröffnet.

Funktionen:

DWriteCore enthält nahezu alle Features von DirectWrite.

Wichtige Einschränkungen:

  • DWriteCore enthält die folgenden DirectWrite Features nicht:
    • Sitzungsbasierte Schriftarten
    • EUDC-Schriftarten (End-User Defined Character, durch Endbenutzer definierte Zeichen)
    • Schriftartenstreaming-APIs
  • Die API für Rendering auf niedriger Ebene wird nur teilweise unterstützt.
  • DWriteCore interoperiert nicht mit Direct2D, aber Sie können IDWriteGlyphRunAnalysis und IDWriteBitmapRenderTarget verwenden.

Weitere Informationen finden Sie unter Übersicht über DWriteCore.

MRT Core

MRT Core ist eine optimierte Version des modernen Ressourcenverwaltungssystems von Windows, das als Teil des Windows App SDK verteilt wird.

Wichtige Einschränkungen:

  • In .NET-Projekten werden Ressourcendateien, die in den Projektordner kopiert wurden, beim Drücken von F5 nicht indiziert, wenn die App bereits erstellt wurde. Erstellen Sie die App als Problemumgehung neu. Weitere Informationen finden Sie im Issue #1503.

  • Wenn .NET-Projekten Ressourcendateien über die Visual Studio-Benutzeroberfläche hinzugefügt werden, werden die Dateien möglicherweise nicht standardmäßig indiziert. Weitere Informationen finden Sie im Issue #1786. Als Problemumgehung entfernen Sie die folgenden Einträge aus der .csproj-Datei:

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

  • Für nicht gepackte C++-WinUI-Apps wird der Ressourcen-URI nicht ordnungsgemäß erstellt. Zur Problemumgehung fügen Sie der .vcxproj-Datei Folgendes hinzu:

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

<PropertyGroup>
    <AppxPriInitialPath></AppxPriInitialPath>   
</PropertyGroup>

Weitere Informationen finden Sie unter Verwalten von Ressourcen mit MRT Core.

Bereitstellung

Neue Features und Updates:

Wichtige Einschränkungen:

  • Der .NET-Wrapper für die Bootstrapper-API ist nur für die Verwendung durch nicht gepackte .NET-Anwendungen vorgesehen, um den Zugriff auf das Windows App SDK zu vereinfachen.
  • Nur mit MSIX gepackte Apps, die vollständig vertrauenswürdig sind oder über die eingeschränkte PackageManagement-Funktion verfügen, haben die Berechtigung, die Bereitstellungs-API zum Installieren der Haupt- und Singletonpaketabhängigkeiten zu verwenden. Unterstützung für teilweise vertrauenswürdige gepackte Apps wird in späteren Releases bereitgestellt.
  • Wenn Sie eine x86-App, die die DeploymentManager.Initialize-Methode verwendet, per F5 auf einem x64-System testen, stellen Sie sicher, dass zuerst das x64-Framework installiert wird, indem Sie WindowsAppRuntimeInstall.exe ausführen. Andernfalls tritt ein NOT_FOUND-Fehler auf, da Visual Studio das x64-Framework nicht bereitstellt, was normalerweise durch Store-Bereitstellung oder Querladen erfolgt.

Weitere Einschränkungen und bekannte Probleme

  • Keine Unterstützung für Buildkonfigurationen mit „Beliebige CPU“: Beim Hinzufügen des Windows App SDK zu einer vorhandenen .NET-Anwendung oder -Komponente, die Beliebige CPU unterstützt, müssen Sie die gewünschte Architektur angeben: x86, x64 oder arm64.

  • Upgrade von .NET 5 auf .NET 6: Beim Upgrade auf der Visual Studio-Benutzeroberfläche können Buildfehler auftreten. Aktualisieren Sie als Problemumgehung das TargetFrameworkPackage der Projektdatei manuell auf Folgendes:

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

  • Eine C#-MSIX-Einzelprojekt-App wird nicht kompiliert, wenn die C++-UWP-Tools nicht installiert sind. Im Fall einer C#-App mit einem MSIX-Einzelprojektpaket müssen Sie die optionale Komponente C++ (v14x)-Tools für Universelle Windows-Plattform installieren.

  • Die zweite Sprach-VSIX kann nicht in Visual Studio 2019 installiert werden, wenn mehrere Versionen von Visual Studio 2019 installiert sind. Wenn Sie über mehrere installierte Versionen von Visual Studio 2019 (z. B. Release und Preview) verfügen und dann die Windows App SDK-VSIX für C++ und C# installieren, tritt bei der zweiten Installation ein Fehler auf. Um das Problem zu beheben, deinstallieren Sie die MSIX-Packtools für Einzelprojekte für Visual Studio 2019 nach der ersten Sprach-VSIX. Weitere Informationen zu diesem Problem finden Sie in diesem Feedback.

  • Eine Alternative zu DispatcherQueue.TryEnqueue (zum Fortsetzen der Ausführung im Warteschlangenthread des Verteilers) besteht darin, die resume_foreground-Hilfsfunktion in der Windows Implementation Library (WIL) zu verwenden:

    1. Fügen Sie dem NuGet-Paket Microsoft.Windows.ImplementationLibrary einen Verweis auf Ihr Projekt hinzu.
    2. Fügen Sie #include <wil/cppwinrt_helpers.h> zu pch.h hinzu.
    3. Fügen Sie #include <winrt/Microsoft.UI.Dispatching.h> zu pch.h hinzu.
    4. Jetzt: co_await wil::resume_foreground(your_dispatcherqueue);.