Freigeben über

Versionshinweise zum Vorschaukanal für das Windows App SDK 1.0

  • Artikel

Wichtig

Der Vorschaukanal wird für die Verwendung in Produktionsumgebungen nicht unterstützt, und Apps, die die Vorschaureleases verwenden, können nicht im Microsoft Store veröffentlicht werden.

Der Vorschaukanal enthält Versionen des Windows App SDK mit Features des Vorschaukanals in späten Entwicklungsphasen. Vorschauversionen enthalten keine experimentellen Features und APIs, können bis zum nächsten stabilen Release jedoch wichtigen Änderungen unterliegen.

Wichtige Links:

Neuestes Vorschaukanal-Release:

Release des neuesten stabilen Kanals:

Version 1.0 Vorschau 3 (1.0.0-preview3)

Vorschau 3 ist das neueste Release des Vorschaukanals für Version 1.0 des Windows App SDK. Vorschau 3 unterstützt alle Features des Vorschaukanals.

Herunterladen von Visual Studio-Erweiterungen (VSIX) für 1.0 Vorschau 3

Hinweis

Wenn Sie bereits Visual Studio-Erweiterungen (VSIX) für das Windows App SDK installiert haben, deinstallieren Sie diese, bevor Sie eine neue Version installieren. Anweisungen finden Sie unter Verwalten von Erweiterungen für Visual Studio.

In der folgenden Tabelle können Sie die Visual Studio-Erweiterungen (VSIX) für das Release 1.0 Vorschau 3 herunterladen. Alle Versionen finden Sie unter Neueste Windows App SDK-Downloads. Konfigurieren Sie zunächst, falls noch nicht geschehen, Ihre Entwicklungsumgebung nach den Schritten unter Installationstools für das Windows App SDK.

Die folgenden Erweiterungen sind auf Ihre Programmiersprache und Version von Visual Studio zugeschnitten.

Downloads für 1.0 Vorschau 3 Beschreibung
C# Erweiterung für Visual Studio 2019 Erstellen von C#-Apps mit der Erweiterung für Visual Studio 2019 für Windows App SDK.
C++ Erweiterung für Visual Studio 2019 Erstellen von C++-Apps mit der Erweiterung für Visual Studio 2019 für Windows App SDK.
C# Erweiterung für Visual Studio 2022 Erstellen von C#-Apps mit der Erweiterung für Visual Studio 2022 für Windows App SDK.
C++ Erweiterung für Visual Studio 2022 Erstellen von C++-Apps mit der Erweiterung für Visual Studio 2022 für Windows App SDK.
Die .exe-Installationsprogramm- und MSIX-Pakete Stellen Sie das Windows App SDK mit Ihrer App mit den .exe-Installationsprogramm- und MSIX-Paketen bereit.

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

WinUI 3 (1.0.0-preview3)

Wir unterstützen jetzt die Bereitstellung von WinUI 3-Apps ohne MSIX-Paketerstellung. Informationen zum Konfigurieren Ihrer WinUI 3-Anwendung zur Unterstützung der nicht gepackten Bereitstellung finden Sie unter Erstellen Ihres ersten WinUI 3-Projekts (Windows App SDK).

Wichtige Einschränkungen:

  • Ungepackte WinUI 3-Anwendungen werden nur unter Windows-Versionen 1909 und höher unterstützt.
  • Ungepackte WinUI 3-Anwendungen werden auf x86 und x64 unterstützt. Arm64-Unterstützung kommt im nächsten stabilen Release hinzu.
  • Es sind MSIX-Paketerstellungstools für Einzelprojekte für Visual Studio 2019 oder Visual Studio 2022 sind für ungepackte Apps erforderlich.
  • In einer ungepackten App erhalten Sie möglicherweise eine Aufforderung zum Installieren von .NET 3.5, die ignoriert werden kann.
  • Einige APIs werden in ungepackten Apps derzeit nicht unterstützt. Das soll im nächsten stabilen Release behoben werden. Einige Beispiele:
  • ListView-, CalendarView- und GridView-Steuerelemente verwenden die falschen Formatvorlagen, was im nächsten stabilen Release behoben werden soll.

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

Weitere Einschränkungen und bekannte Probleme:

  • Ungepackte Apps werden unter Windows 10, Version 1809 nicht unterstützt. Das soll im nächsten Release im stabilen Kanal behoben werden.

  • 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.

  • In diesem Release werden die Projektvorlagen Leere App, gepackt (WinUI 3 in Desktop) für C# und C++ eingeführt. Diese Vorlagen ermöglichen Ihnen die Aufnahme Ihrer App in ein MSIX-Paket ohne Verwendung eines separaten Paketerstellungprojekts (siehe Packen Ihrer App mit Einzelprojekt-MSIX). Diese Vorlagen haben einige bekannte Probleme in diesem Release:

    • Menüelement „Veröffentlichen“ fehlt, bis Visual Studio neu gestartet wird. Beim Erstellen einer neuen App 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.

    • Fehler beim Hinzufügen von C++-Projektverweisen für statische/dynamische Bibliotheken zu C++-Apps anhand der MSIX-Paketerstellung für Einzelprojekte. Visual Studio zeigt einen Fehler an, dass das Projekt nicht als Verweis hinzugefügt werden kann, weil die Projekttypen nicht kompatibel sind.

    • Fehler beim Verweisen auf ein benutzerdefiniertes Benutzersteuerelement in einem Klassenbibliotheksprojekt. Die Anwendung stürzt ab mit der Fehlermeldung, dass das System den angegebenen Pfad nicht finden kann.

    • C#- oder C++-Vorlage für Visual Studio 2019. Beim Versuch, das Projekt zu erstellen, tritt der Fehler „Das Projekt weiß nicht, wie das Profil Projektname auszuführen ist“ auf. Installieren Sie zum Beheben dieses Problems die Erweiterung zu MSIX-Paketerstellungstools für Einzelprojekte.

    • C#-Vorlage für Visual Studio 2019 und Visual Studio 2022. Wenn in Visual Studio nach Debuggen oder Ohne Debuggen starten Ihre App nicht bereitstellt und ausgeführt wird (und kein Feedback von Visual Studio vorhanden ist), klicken Sie in Visual Studio im Projektmappen-Explorer zum Auswählen auf den Pojektknoten und versuchen Sie es erneut.

    • C#-Vorlage für Visual Studio 2019 und Visual Studio 2022. Es tritt der folgende Fehler auf, wenn Sie versuchen, Ihr Projekt auf Ihrem Entwicklungscomputer auszuführen oder zu debuggen: „Das Projekt muss vor dem Debuggen bereitgestellt werden. Aktivieren Sie „In Configuration Manager bereitstellen“. Aktivieren Sie die Bereitstellung für Ihr Projekt im Configuration Manager, um dieses Problem zu beheben. Ausführliche Anweisungen finden Sie unter Erstellen Ihres ersten WinUI 3-Projekts (Windows App SDK).

    • C++-Vorlage für Releases von Visual Studio 2022, Version 17.0 bis Vorschau 4. Beim ersten Versuch, das Projekt auszuführen, tritt der folgende Fehler auf: „Es gab Bereitstellungsfehler“. Zum Beheben dieses Problems müssen Sie Ihr Projekt ein zweites Mal ausführen oder bereitstellen. Das Problem wird in Visual Studio 2022, Version 17.0 Vorschau 7 behoben.

  • 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.

  • C#-Projekte mit 1.0 Vorschau 3 müssen das folgende .NET SDK verwenden: .NET 6 SDK oder höher (siehe Herunterladen von .NET und .NET 5 erreicht das Ende des Supports am 10. Mai 2022).

  • 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);.

Wichtiges Problem, das sich auf 1.0 Vorschau 1 und Vorschau 2 auswirkt

Version 1.0 Vorschau 1 und Vorschau 2 des Windows App SDK enthält einen Mechanismus zum Bereinigen aller von einer gepackten App vorgenommenen Änderungen an Umgebungsvariablen, wenn diese App deinstalliert wird. Dieses Feature befindet sich in einem experimentellen Zustand, und das erste Release enthält einen bekannten Bug, der die Umgebungsvariable PATH des Systems beschädigen kann.

Die Vorschau 1 und Vorschau 2 beschädigt jede Umgebungsvariable PATH, die das Erweiterungszeichen % enthält. Dies geschieht bei jedem Deinstallieren einer gepackten App, unabhängig davon, ob diese App das Windows App SDK verwendet.

Siehe auch Problem der Beschädigung der Umgebungsvariable PATH.

Details

Der Eintrag PATH des Systems wird unter dem Pfadwert im folgenden Schlüssel in der Windows-Registrierung gespeichert:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Wenn Sie den Registrierungs-Editor (regedit.exe) starten, können Sie den obigen Pfad kopieren und in die Breadcrumb-Leiste einfügen (direkt unter der Menüleiste), und zum Lokalisieren der Taste die Eingabetaste drücken.

Der Pfadwert dieses Schlüssels sollte vom Typ REG_EXPAND_SZ sein, wird aber durch den Bug in REG_SZ geändert. Und dadurch wird die Umgebungsvariable PATH des Systems unbrauchbar, wenn sie das Variablenerweiterungszeichen % enthält.

Betroffene Releases

Abmilderung

Führen Sie die folgenden Schritte aus, um Ihren Computer wieder in einen ordnungsgemäßen Zustand zu versetzen:

  1. Überprüfen Sie, ob der PATH in der Registrierung beschädigt ist, und setzen Sie ihn ggf. durch Ausführen des folgenden Skripts zurück.

    Sie können Schritt 1 mit dem folgenden Windows PowerShell-Skript ausführen (PowerShell Core funktioniert nicht). Führen Sie es mit erhöhten Rechten aus.

    # This script must be run from an elevated Windows PowerShell
# window (right-click Windows PowerShell in the Start menu,
# and select Run as Administrator).

# If the PATH in the Registry has been set to REG_SZ, then delete
# it, and recreate it as REG_EXPAND_SZ.

$EnvPath = 'Registry::HKLM\System\CurrentControlSet\Control\Session Manager\Environment'
$Environment=Get-Item $EnvPath
$PathKind = $Environment.GetValueKind('Path')

if ($PathKind -ne 'ExpandString') {
  $Path = $Environment.GetValue('Path')
  Remove-ItemProperty $EnvPath -Name Path
  New-ItemProperty $EnvPath -Name Path -PropertyType ExpandString -Value $Path
}

  2. Deinstallieren Sie alle Apps, die das Windows App SDK 1.0 Vorschau 1 oder Vorschau 2 verwenden (siehe folgendes Skript).

  3. Deinstallieren Sie die Windows App SDK 1.0 Vorschau 1/Vorschau 2-Pakete, einschließlich des Pakets, das den Bug enthält (siehe folgendes Skript).

    Sie können die Schritte 2 und 3 mit dem folgenden Windows PowerShell-Skript ausführen (PowerShell Core funktioniert nicht). Führen Sie es mit erhöhten Rechten aus.

    # This script must be run from an elevated Windows PowerShell
# window (right-click Windows PowerShell in the Start menu,
# and select Run as Administrator).

# Remove the Windows App SDK 1.0 Preview1/2, and all apps that use it.

$winappsdk = "Microsoft.WindowsAppRuntime.1.0-preview*"
Get-AppxPackage | Where-Object { $_.Dependencies -like $winappsdk } | Remove-AppxPackage
Get-AppxPackage $winappsdk | Remove-AppxPackage

Behebung in Windows App SDK 1.0 Vorschau 3

Das Feature, durch das die Umgebungsvariable PATH beschädigt wird, wird im kommenden Release von Windows App SDK 1.0 Vorschau 3 entfernt. Es kann zu einem späteren Zeitpunkt nach Beheben aller Bugs und gründlichen Tests wieder eingeführt werden.

Wir empfehlen die Verwendung von Version 1.0 Vorschau 3.

Version 1.0 Vorschau 2 (1.0.0-preview2)

Wichtig

Version 1.0 Vorschau 1 und Vorschau 2 enthalten einen kritischen Bug. Wenn Sie bereits eine dieser Vorschauversionen installiert haben, verweisen wir Sie auf Informationen zum Beheben des Problems. Wir empfehlen stattdessen die Verwendung von Version 1.0 Vorschau 3.

Das ist das neueste Release des Vorschaukanals für Version 1.0. Es unterstützt alle Features des Vorschaukanals.

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

WinUI 3 (1.0.0-preview2)

Neue Aktualisierungen:

  • Steuerelemente wurden so aktualisiert, dass sie den neuesten Windows-Formatvorlagen von WinUI 2.6 entsprechen.
  • Einzelprojekt-MSIX wird unterstützt.
  • WinUI 3-Paket kann jetzt auf Build 17763 und höher abzielen. Weitere Informationen finden Sie im Issue 921.
  • Die In-App-Symbolleiste wird unterstützt. Die In-App-Symbolleiste und die vorhandene Unterstützung der visuellen Struktur Hot Reload/Live erfordern jedoch das kommende Release von Visual Studio 17.0 Vorschau 5, das später im Oktober verfügbar ist.

Bug behoben: WebView2Runtime-Text ist jetzt lokalisiert.

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

Windowing (1.0.0-preview2)

In diesem Release werden Aktualisierungen der AppWindow-Klasse eingeführt. In diesem Release kamen keine wichtigen neuen Features hin, aber es gibt Änderungen an Methodennamen und Eigenschaften, und einige Rückgabewerte wurden entfernt. Detaillierte Informationen zu den Aktualisierungen finden Sie in der Dokumentation und in den Beispielen. Wenn Sie mit AppWindow in den Releases der experimentellen Version 1.0 oder 1.0 Vorschau 1 gearbeitet haben, erwarten Sie einige Änderungen an Ihrem Code.

Neue Aktualisierungen:

  • Die Klasse AppWindowConfiguration wurde entfernt. Die Eigenschaften dieser Klasse stehen jetzt in AppWindow selbst oder in den Presenter-Klassen zur Verfügung.
  • Die meisten bool-Rückgabewerte für die WinRT-API-Methoden in diesem Bereich wurden entfernt und sind jetzt void, da diese Methoden immer erfolgreich sind.
  • Die C#-ImportDll-Aufrufe sind für GetWindowIdFromWindow und GetWindowFromWindowId nicht mehr erforderlich. Verwenden Sie stattdessen die .NET-Wrapper-Methoden, die in der Klasse Microsoft.UI.Win32Interop zur Verfügung stehen.

Wichtige Einschränkungen:

  • Das Windows App SDK verfügt derzeit über keine Methoden zum Anfügen von UI-Framework-Inhalten an AppWindow. Sie sind auf die Verwendung der Interop-Zugriffsmethoden beschränkt.
  • Die Anpassung der Fenstertitelleiste funktioniert nur unter Windows 11. Prüfen Sie mit der IsCustomizationSupported-Methode, ob das Feature zur Anpassung der Titelleiste unterstützt wird. Wir planen die Vereinheitlichung dieser Funktionalität mit älteren Versionen.

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

Eingabe (1.0.0-preview2)

Neue Aktualisierungen:

  • Verbesserte Unterstützung der Eingabe über Präzisionstouchpads.

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. Weitere Informationen finden Sie in der Dokumentation.

MRT Core (1.0.0-preview2)

Neue Aktualisierungen:

  • App-Entwickler können jetzt die Indizierung einer Bilddatei oder einer RESW-Datei in der PRI-Datei in .NET-Projekten deaktivieren. Weitere Informationen finden Sie im Issue 980.

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.
  • In .NET-Projekten werden vorhandene Ressourcendateien, die aus einem externen Ordner hinzugefügt wurden, ohne manuelle Einstellung der Build-Aktion nicht indiziert. Legen Sie zum Umgehen dieses Problems die Build-Aktion in Visual Studio fest: Content für Bilddateien und PRIResource für RESW-Dateien. Weitere Informationen finden Sie im Issue 1504.

Bereitstellung für nicht gepackte Apps

Neue Features:

  • Windows App SDK 1.0 Vorschau 2 führt einen .NET-Wrapper für die Bootstrapper-API ein (siehe Verwenden der Windows App SDK-Runtime für gepackte Apps mit externem Speicherort oder nicht gepackte Apps). Die Bootstrapper-API ist eine Reihe nativer C/C++-Funktionen, die ungepackte Apps verwenden müssen, um dynamisch eine Abhängigkeit vom Windows App SDK-Frameworkpaket zur Laufzeit zu einzugehen. Der .NET-Wrapper bietet eine einfachere Möglichkeit zum Aufrufen der Bootstrapper-API aus .NET-Apps, einschließlich Windows Forms- und WPF-Apps. Der .NET-Wrapper für die Bootstrapper-API ist in der Microsoft.WindowsAppRuntime.Bootstrap.Net.dll-Assembly verfügbar, die in Ihrem App-Projekt lokal vorhanden ist. Weitere Informationen zum .NET-Wrapper finden Sie in der .NET-Wrapper-Bibliothek.
  • Gepackte Apps können jetzt zum Installieren der Standard- und Singleton-MSIX-Pakete auf dem Computer die Bereitstellungs-API verwenden. Die Standard- und Singletonpakete sind Teil des mit der App installieren Frameworkpakets, aber aufgrund einer Einschränkung beim Windows-Anwendungsmodell erfordern gepackte Apps diesen zusätzlichen Schritt zum Installieren dieser Pakete. Weitere Informationen zur Funktionsweise der Bereitstellungs-API finden Sie unter Windows App SDK-Bereitstellungsleitfaden für frameworkabhängige gepackte Apps.

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.

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.

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 3-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 3-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 3-Apps können Sie Main bei Bedarf als asynchron deklarieren. Bei C++-WinUI 3- 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.

Weitere Einschränkungen und bekannte Probleme:

  • Version 1.0 Vorschau 1 und Vorschau 2 enthalten einen kritischen Bug. Wenn Sie bereits eine dieser Vorschauversionen installiert haben, verweisen wir Sie auf Informationen zum Beheben des Problems. Wir empfehlen stattdessen die Verwendung von Version 1.0 Vorschau 3.

  • In diesem Release werden die Vorlagen Leere App, gepackt (WinUI 3 in Desktop) für C#- und C++-Projekte eingeführt. Diese Vorlagen ermöglichen Ihnen die Aufnahme Ihrer App in ein MSIX-Paket ohne Verwendung eines separaten Paketerstellungprojekts. Diese Vorlagen haben einige bekannte Probleme in diesem Release:

    • C#-Vorlage für Visual Studio 2019. Beim Versuch, das Projekt zu erstellen, tritt der Fehler „Das Projekt weiß nicht, wie das Profil Projektname auszuführen ist“ auf. Installieren Sie zum Beheben dieses Problems die Erweiterung zu MSIX-Paketerstellungstools für Einzelprojekte.

    • C#-Vorlage für Visual Studio 2019 und Visual Studio 2022. Es tritt der folgende Fehler auf, wenn Sie versuchen, Ihr Projekt auf Ihrem Entwicklungscomputer auszuführen oder zu debuggen: „Das Projekt muss vor dem Debuggen bereitgestellt werden. Aktivieren Sie „In Configuration Manager bereitstellen“. Aktivieren Sie die Bereitstellung für Ihr Projekt im Configuration Manager, um dieses Problem zu beheben. Ausführliche Anweisungen finden Sie unter Erstellen Ihres ersten WinUI 3-Projekts (Windows App SDK).

    • C++-Vorlage für Visual Studio 2019 und Visual Studio 2022. In diesem Release sind diese Projekte auf das Aufrufen der Teilmenge von Win32-APIs beschränkt, die von UWP-Apps aufgerufen werden können. Die Vorlage Leere App, gepackt mit WAP (WinUI 3 in Desktop) ist von diesem Problem nicht betroffen.

    • C++-Vorlage für Releases von Visual Studio 2022, Version 17.0 bis Vorschau 4. Beim ersten Versuch, das Projekt auszuführen, tritt der folgende Fehler auf: „Es gab Bereitstellungsfehler“. Zum Beheben dieses Problems müssen Sie Ihr Projekt ein zweites Mal ausführen oder bereitstellen. Das Problem wird in Visual Studio 2022, Version 17.0 Preview 5, behoben.

  • Die Pushbenachrichtigungs-API (Microsoft.Windows.PushNotifications-Namespace) ist im Release 1.0 Vorschau 2 fälschlicherweise enthalten. Dies handelt sich immer noch um ein experimentelles Feature, für dessen Verwendung Sie stattdessen das experimentelle Release 1.0 installieren müssen. Dieses Feature wird im bevorstehenden Release 1.0 entfernt.

  • Die App-Lebenszyklus-API (Microsoft.Windows.AppLifecycle-Namespace) enthält fälschlicherweise das Attribut „experimentell“ im Release 1.0 Vorschau 2. Das Attribut „experimentell“ wird im nächsten Release aus dieser API entfernt.

  • 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.

  • C#-Projekte mit 1.0 Vorschau 2 müssen das folgende .NET SDK verwenden: .NET 6 SDK oder höher (siehe Herunterladen von .NET und .NET 5 erreicht das Ende des Supports am 10. Mai 2022).

  • 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);.

Version 1.0 Vorschau 1 (1.0.0-preview1)

Wichtig

Version 1.0 Vorschau 1 und Vorschau 2 enthalten einen kritischen Bug. Wenn Sie bereits eine dieser Vorschauversionen installiert haben, verweisen wir Sie auf Informationen zum Beheben des Problems. Wir empfehlen stattdessen die Verwendung von Version 1.0 Vorschau 3.

Das ist das erste Release des Vorschaukanals für Version 1.0. Es unterstützt alle Features des Vorschaukanals.

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

WinUI 3 (1.0.0-preview1)

Dieses Release von WinUI 3 konzentriert sich auf die Weiterentwicklung von 1.0 mit Programmfehlerbehebungen.

  • Neue Features: Keine neuen Features in Vorschau 1.
  • Behobene Probleme: Eine vollständige Liste der in diesem Release behobenen Probleme finden Sie in unserem GitHub-Repository.

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

Windowing (1.0.0-preview1)

Dieses Release versetzt die in der experimentellen Version 1 eingeführte Windowing-API in einen Vorschaustatus. Es gibt keine wichtigen neuen Features in diesem Release, da es sich auf Programmfehlerbehebungen, Stabilität und Anpassungen der API-Signatur konzentriert. Die beachtenswerten Änderungen und Ergänzungen sind unten aufgeführt.

Neue Features:

  • DisplayAreaWatcher wurde zu den Windowing-APIs hinzugefügt. Sie ermöglicht es Entwickler*innen Änderungen in der Anzeigetopologie zu beobachten und DisplayAreas zu enumerieren, die derzeit im System definiert sind.
  • AppWindow unterstützt jetzt das Festlegen des Fenstersymbols über die SetIcon-Methode, und AppWindowTitleBar unterstützt jetzt die Auswahlmöglichkeit, das Fenstersymbol zusammen mit dem Systemmenü über die Eigenschaft IconShowOptions ein- oder auszublenden.

Wichtige Einschränkungen:

  • Dieses Release von AppWindows ist derzeit nur für Win32-Apps verfügbar (sowohl gepackt als auch ungepackt).
  • Das Windows App SDK verfügt derzeit über keine Methoden zum Anfügen von UI-Framework-Inhalten an AppWindow. Sie sind auf die Verwendung der Interop-Zugriffsmethoden beschränkt.
  • Die Anpassung der Fenstertitelleiste funktioniert nur unter Windows 11. Prüfen Sie mit der IsCustomizationSupported-Methode, ob das Feature zur Anpassung der Titelleiste unterstützt wird. Wir planen die Vereinheitlichung dieser Funktionalität mit älteren Versionen.

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

Eingabe (1.0.0-preview1)

Dieses Release verfügt über einige neue Features für die Eingabe-API. Die beachtenswerten Änderungen und Ergänzungen sind unten aufgeführt.

Neue Features und Updates:

  • PointerPredictor bietet den für die Eingabelatenz empfindlichen Anwendungen wie Freihandanwendungen die Möglichkeit, Eingabepunktpositionen für bis zu 15 ms in der Zukunft vorherzusagen, um eine bessere Latenz und reibungslose Animation zu erzielen.
  • Mit PenDeviceInterop können Sie mit der FromPointerPoint-Methode einen Verweis auf Windows.Devices.Input.PenDevice abrufen.
  • InputCursor ermöglicht eine explizite Unterscheidung zwischen voreingestellten Systemcursortypen und benutzerdefinierten Cursortypen, indem der in CoreCursor vorhandene Typ „Custom“ entfernt und das Objekt CoreCursor in separate Objekte aufgeteilt wird.
  • Aktualisierungen für InputCursor-APIs.
  • GestureRecognizer wurde aus dem experimentellen Status zu Microsoft.UI.Input verlagert.
  • PointerPoint wurde aus dem experimentellen Status zu Microsoft.UI.Input verlagert.
  • Maus-, Touch- und Stifteingaben werden für WinUI 3-Drag & Drop vollständig unterstützt.

Wichtige Einschränkungen:

  • Dieses Release von Eingabe-APIs hat bekannte Probleme mit Windows Version 1809.
  • MRT Core wird von den Untertypen von InputCursor noch nicht unterstützt.
  • Die direkte Verwendung der Plattform-SDK-API Windows.UI.Core.CoreDragOperation funktioniert mit WinUI 3-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.

MRT Core (1.0.0-preview1)

Ab Version 1.0 Vorschau 1 wurden MRT-Core-APIs vom Namespace Microsoft.ApplicationModel.Resources zum Namespace Microsoft.Windows.ApplicationModel.Resources verlagert.

Weitere Einschränkungen und bekannte Probleme:

  • Version 1.0 Vorschau 1 und Vorschau 2 enthalten einen kritischen Bug. Wenn Sie bereits eine dieser Vorschauversionen installiert haben, verweisen wir Sie auf Informationen zum Beheben des Problems. Wir empfehlen stattdessen die Verwendung von Version 1.0 Vorschau 3.

  • Bei Projekten, die mit der C++-Projektvorlage Leere App, gepackt mit WAP (WinUI 3 in Desktop) erstellt wurden, trotz standardmäßig der folgende Buildfehler auf: fatal error C1083: Cannot open include file: 'winrt/microsoft.ui.dispatching.co_await.h': No such file or directory. Entfernen Sie zum Beheben dieses Problems die folgende Codezeile aus der Datei pch.h. Dieses Problem wird im nächsten Release behoben.

    #include <winrt/microsoft.ui.dispatching.co_await.h>

  • 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);.

  • Keine Unterstützung für eine CPU-Buildkonfiguration: Das Windows App SDK ist in systemeigenem Code geschrieben und unterstützt somit keine CPU-Buildkonfigurationen . Die WinUI 3-Vorlagen in Visual Studio lassen nur architekturspezifische Builds zu. 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.

  • .NET-Apps müssen auf Build 18362 oder höher ausgerichtet sein: Ihr TFM muss auf net6.0-windows10.0.18362 oder höher festgelegt sein, und die <TargetPlatformVersion> Ihres Paketprojekts muss auf 18362 oder höher festgelegt sein. Weitere Informationen finden Sie in diesem bekannten Issue auf GitHub.

  • C#-Projekte mit 1.0 Vorschau 1 müssen das folgende .NET SDK verwenden: .NET 6 SDK oder höher (siehe Herunterladen von .NET und .NET 5 erreicht das Ende des Supports am 10. Mai 2022).

  • Unter Windows 10, Version 1809 nicht unterstützte ungepackte Apps: Dies sollte im nächsten Release behoben werden.