Versionshinweise zum stabilen Kanal für das Windows App SDK

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.

Die folgenden Releases des stabilen Kanals sind derzeit verfügbar:

• Version 1.5
• Version 1.4
• Version 1.3
• Version 1.2
• Version 1.1
• Version 1.0
• Version 0.8
• Version 0.5

Wenn Sie für eine vorhandene App ein Upgrade von einer älteren Version des Windows App SDK auf eine neuere Version ausführen möchten, finden Sie weitere Informationen unter Aktualisieren vorhandener Projekte auf das neueste Release von Windows App SDK.

Downloads für das Windows App SDK

Hinweis

Die Windows App 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.5

Version 1.5.1 (1.5.240311000)

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

• Es wurde ein Problem behoben, bei dem eigenständige Apps möglicherweise nicht erstellt werden konnten, da „map.html“ nicht kopiert werden konnte.
• Es wurde ein Problem behoben, bei dem MapControl nicht initialisiert werden konnte, weil gültige Token abgelehnt wurden. Weitere Informationen finden Sie unter GitHub #9324.
• Es wurde ein Problem behoben, bei dem MapControl mit einem blauen Hintergrund geladen wurde. Weitere Informationen finden Sie unter GitHub #9377.
• Es wurde ein Problem behoben, bei dem ein NavigationViewItem durch einmaliges Klicken auf das Chevron nicht korrekt erweitert oder reduziert wurde. Dies führte auch dazu, dass Menüs durch Klicken auf das Chevron im PaneDisplayMode="Top"-Modus als leer angezeigt wurden. Weitere Informationen finden Sie unter GitHub #9423 und #9426.
• Es wurde ein Problem behoben, bei dem durch das Antippen eines NavigationViewItem per Berührung oder Stift verhindert wurde, dass das Element auf zukünftige Eingaben reagiert. Weitere Informationen finden Sie unter GitHub #9429.
• Es wurde ein Absturz beim Klicken auf ein Element im NavigationView.PaneFooter-Bereich behoben. Weitere Informationen finden Sie unter GitHub #9396.
• Es wurde ein Problem behoben, bei dem Menüsymbole manchmal an der falschen Stelle angezeigt wurden. Weitere Informationen finden Sie unter GitHub #9409.
• Es wurde ein Problem behoben, bei dem der Acryl-Hintergrund in Menüs erst dann angezeigt wurde, wenn vom Fenster weg- und wieder zum Fenster zurückgewechselt wurde. Weitere Informationen finden Sie unter GitHub #9406.
• Es wurde ein möglicher Absturz bei der Initialisierung von TextBox/RichEditBox behoben. Weitere Informationen finden Sie unter GitHub #9216.
• Es wurden einige auffällige Ausnahmen behoben, die NavigationView beim Zerstören ausgelöst und abgefangen hat.
• Es wurde ein Problem behoben, bei dem aufgrund einer fehlerhaften PointerCaptureLost-Meldungsauslösung eine „Zwei-Finger-Zoom“-Geste manchmal als Schwenken oder Tippen angezeigt wurde.

Version 1.5

In den folgenden Abschnitten werden neue und aktualisierte Features und bekannte Probleme für Version 1.5 beschrieben.

In einer vorhandenen Windows App SDK 1.4-App können Sie Ihr NuGet-Paket auf 1.5.240227000 aktualisieren (weitere Informationen finden Sie im Abschnitt Aktualisieren eines Pakets in Installieren und Verwalten von Paketen in Visual Studio mit dem NuGet-Paket-Manager).

Die aktualisierten Runtime- und MSIX-Pakete finden Sie unter Downloads für das Windows App SDK.

XAML Islands Laufzeit- und Shutdown-Updates

Es gibt einen Verhaltensunterschied zwischen WinAppSDK 1.4 und WinAppSDK 1.5 für XAML-inselbasierte Anwendungen, wenn das letzte XAML-Fenster auf einem Thread geschlossen wird.

• In WinAppSDK 1.4 beendet die XAML-Laufzeitumgebung die Ereignisschleife des Threads immer dann, wenn das letzte XAML-Fenster eines Threads geschlossen wird.
• In WinAppSDK 1.5:
  • Wenn es sich bei Ihrer App um eine WinUI-Desktop-App handelt, ist das Standardverhalten immer noch dasselbe wie in WinAppSDK 1.4.
  • Wenn Sie XAML für die DesktopWindowXamlSource („XAML-Inseln“) API verwenden, ist das Standardverhalten jetzt, dass XAML die Ereignisschleife des Threads nicht automatisch beendet.
  • In beiden Modi können Sie dieses Verhalten ändern, indem Sie die Eigenschaft Application.DispatcherShutdownMode festlegen.

Weitere Informationen finden Sie in der Dokumentation für die Application.DispatcherShutdownMode Eigenschaft, sofern verfügbar. Dies vervollständigt den GitHub-Vorschlag #8492.

Es gibt einen Verhaltensunterschied zwischen WinAppSDK 1.4 und WinAppSDK 1.5 für XAML-Insel-basierte Anwendungen in der Lebensdauer der XAML-Laufzeit:

• In WinAppSDK 1.4 wird die XAML-Laufzeit auf einem Thread beendet, wenn entweder alle WindowsXamlManager- und DesktopWindowXamlSource-Objekte auf einem bestimmten Thread geschlossen oder heruntergefahren werden oder die auf diesem Thread laufende DispatcherQueue heruntergefahren wird (in diesem Fall wird die XAML-Laufzeit während der DispatcherQueue.FrameworkShutdownStarting-Phase heruntergefahren).
• In WinAppSDK 1.5 wird die XAML-Laufzeit auf einem Thread nur dann beendet, wenn die auf diesem Thread laufende DispatcherQueue beendet wird (die XAML-Laufzeit wird immer während der Phase DispatcherQueue.FrameworkShutdownStarting beendet).

Weitere Informationen finden Sie in der Dokumentation zur WindowsXamlManager Klasse, sofern verfügbar.

Es gibt einen Verhaltensunterschied auf WindowsXamlManager.InitializeForCurrentThread():

• In WinAppSDK 1.4 gibt WindowsXamlManager.InitializeForCurrentThread() bei jedem Aufruf eine eindeutige Instanz eines WindowsXamlManager-Objekts zurück.
• In WinAppSDK 1.5 gibt WindowsXamlManager.InitializeForCurrentThread() eine vorhandene Instanz zurück, wenn bereits eine auf dem Thread existiert. Close/Dispose() wird jetzt ignoriert.

WinUI-Karten-Steuerelement

Die WinUI Maps-Steuerung ist jetzt verfügbar! Dieses Steuerelement wird von WebView2 und Azure Karten unterstützt und stellt die folgenden Features bereit:

• Verschieben und Zoomen mit den Kartenschaltflächen oder per Toucheingabe.
• Ändern des Stils der Karte in Satelliten-, Gelände- oder Straßenansicht.
• Programmgesteuertes Hinzufügen von interagierbaren Pins mit vom Entwickler anpassbaren Symbolen zur Karte.
• Entwickleranpassung für die Ausrichtung der Karte beim ersten Laden.
• Kontrolle für Entwickler über das Ausblenden oder Anzeigen der Schaltflächen zum Schwenken, Zoomen und Kartenstilen.

Hinweis

Um das Maps Steuerelement zu verwenden, benötigen Sie einen Azure Karten-Schlüssel. Informationen zum Erstellen des Schlüssels finden Sie auf der Dokumentationsseite von Azure Karten zum Erstellen einer Web-App.

Das Maps Steuerelement ist völlig neu und wir freuen uns über Ihr Feedback, um ihre zukünftige Richtung zu bewerten!

Neues SelectorBar-Steuerelement

In Version 1.5 haben wir ein neues Steuerelement SelectorBar hinzugefügt, mit dem Benutzer zwischen mehreren Datenansichten wechseln können. Dieses Steuerelement war auf unserer 1.5-Roadmap bisher als „SegmentedControl“ bekannt.

Beschriftungen in der CommandBarFlyout primäre Befehle

Das Bildmaterial von CommandBarFlyout wurde aktualisiert, um eine Textbeschriftung für die Elemente im primären Befehlsbereich anzuzeigen, wenn die Eigenschaft Label auf AppBarButton eingestellt wurde. Bisher wurde für die primären Befehle im Bereich CommandBarFlyout nur ein Symbol angezeigt, jetzt können sie sowohl ein Symbol als auch eine Beschriftung anzeigen, um die Benutzerfreundlichkeit zu verbessern.

WebView2-Unterstützung für benutzerdefinierte Umgebungen/Optionen

Das WinUI WebView2-Steuerelement bietet nun die Möglichkeit, das zugrunde liegende CoreWebView2 Objekt mit einem benutzerdefinierten CoreWebView2Environment und CoreWebView2ControllerOptions anzupassen. So kann der App-Autor einen alternativen Pfad angeben, von dem aus die WebView2Runtime geladen werden soll, einen anderen UserDataFolder verwenden oder Optionen wie IsPrivateModeEnabled und ScriptLocale setzen.

Unterstützung für .NET 8

In einer kürzlich veröffentlichten Version 1.4 haben wir Unterstützung für .NET 8 hinzugefügt, aber die Warnung vor der Verwendung von plattformspezifischen RIDs wurde beibehalten. In Version 1.5 haben wir diese Arbeit abgeschlossen, sodass die Warnung nicht mehr vorhanden ist.

Verbesserte Fehlersuche und Verfügbarkeit des Quellcodes

Wir injizieren jetzt Github-Source-Server-Informationen für den Code im Microsoft-ui-xaml-Repository in unsere öffentlichen Symbole, sodass Debugger den Quellcode automatisch herunterladen können. Wir haben auch andere Korrekturen und Verbesserungen an unseren Symbolen im gesamten WinAppSDK vorgenommen, um die Debugging-Erfahrung zu verbessern.

Verbesserte Funktionalität zum Debuggen von Layout-Zyklen

Das Debuggen von Layout-Zyklen in einer WinUI-Applikation kann eine Herausforderung sein. Daher bietet das DebugSettings-Objekt in Version 1.5 nun Optionen zum Aktivieren einer verbesserten Protokollierung und von Haltepunkten für den Layout-Prozess, um das Debuggen und Beheben von Layout-Zyklen in der App zu erleichtern.

Weitere neue Funktionen aus dem gesamten WinAppSDK

• Unterstützung für das PublishSingleFile-Bereitstellungsmodell hinzugefügt. Weitere Informationen zu PublishSingleFile finden Sie in der Dokumentation zur Bereitstellung einzelner Dateien.
• Verbesserungen bei der Unterstützung von Bildschirmlesegeräten, der Textskalierung und anderen barrierefreien Funktionen.
• Verschiedene Stabilitäts- und Leistungsverbesserungen basierend auf unserem priorisierten GitHub-Bug-Backlog.

Neue Funktionen werden separat veröffentlicht

Neue Versionen der WinAppSDK Visual Studio Templates für C# und C++ werden über den Visual Studio Marketplace veröffentlicht und erscheinen ein paar Wochen nach der Veröffentlichung von 1.5. Mit der neuen Version können die Vorlagen nun unabhängig von WinAppSDK-Releases veröffentlicht werden, was uns mehr Flexibilität bei der Bereitstellung von Updates für Kunden gibt.

Andere bereits geplante Funktionen

In 1.5 haben wir Fortschritte bei den folgenden Funktionen gemacht, die wir in unserer Roadmap angekündigt, aber nicht fertiggestellt haben. Sie werden bis zum Zeitrahmen 1.6 fortgesetzt.

• Registerkarten-Fenster
• Drag-n-Drop-Unterstützung für WebView2
• Untersuchungen zur Tabellenansicht und zur Tintensteuerung

Die dynamische Beleuchtung wurde vorerst von der Roadmap gestrichen.

Bekannte Probleme

• Bei der Verwendung von Bibliotheken, die Ressourcen wie .xaml-Dateien enthalten, kann es vorkommen, dass Sie zur Laufzeit eine Fehlermeldung erhalten, die besagt, dass diese Ressourcen nicht gefunden werden können. In diesem Fall kann es erforderlich sein, <ShouldComputeInputPris>true</ShouldComputeInputPris> in die Projektdatei einzufügen, um sicherzustellen, dass diese Ressourcen aufgenommen werden.
• Das Klicken auf den Chevron eines NavigationViewItem wird nicht mehr korrekt mit einem einzigen Klick erweitert oder reduziert. Ein Doppelklick funktioniert immer noch, ebenso wie ein Klick an anderer Stelle auf NavigationViewItem.

Fehlerkorrekturen

• Es wurde ein Problem behoben, bei dem StackPanel Abstände auf eingeklappte Elemente anwandte. Weitere Informationen finden Sie im GitHub-Issue #916.
• Es wurden Probleme behoben, bei denen die Bildlaufsteuerung nach dem Schließen eines anderen Anwendungsfensters nicht mehr funktionierte. Weitere Informationen finden Sie in den GitHub-Ausgaben #9292 und #9355.
• Ein Absturz wurde behoben, wenn DebugSettings.EnableFrameRateCounter auf true gesetzt wurde, bevor das erste Bild gerendert wurde. Weitere Informationen finden Sie im GitHub-Issue #2835.
• Ein möglicher Kompilierfehler für C++ wurde behoben, bei dem einige Header nicht die notwendigen Abhängigkeiten enthielten. Beachten Sie, dass sich die Änderung der Reihenfolge #include auf einige Anwendungen auswirken kann, z. B. durch einen Kompilierfehler für IInspectable, wenn die Anwendung eine Version von C++/WinRT verwendet, die älter als 2023 ist. Weitere Informationen finden Sie im GitHub-Issue #9014.
• Es wurde ein Problem behoben, bei dem ElementName Bindungen innerhalb der ItemsRepeaterDataTemplatenicht funktionierten. Weitere Informationen finden Sie im GitHub-Issue #560.
• Es wurden Abstürze behoben, wenn eine Anwendung unter Visual Studio mit aktivierter In-App-Symbolleiste ausgeführt wurde. Visual Studio 17.8 Preview 2 oder höher ist erforderlich, um die Korrekturen vollständig nutzen zu können. Weitere Informationen finden Sie im GitHub-Issue #8806.
• Es wurde ein Problem behoben, bei dem AnnotatedScrollbar manchmal abstürzen konnte, wenn man schnell scrollte.
• Ein Problem wurde behoben, bei dem der Menütext manchmal abgeschnitten wurde.
• Es wurde ein Problem behoben, bei dem Lehrtipps keinen richtigen Fokus erhalten haben. Weitere Informationen finden Sie im GitHub-Issue #3257.
• Es wurde ein Problem behoben, das zum Absturz der Anwendung führte, wenn beim Start TailVisibility von TeachingTip auf Collapsed gesetzt wurde. Weitere Informationen finden Sie im GitHub-Issue #8731.
• Ein Problem mit der Behandlung von PRI-Dateien bei der Verwendung von Bibliotheken wurde behoben. Weitere Informationen finden Sie im GitHub-Issue #8857.
• Es wurde ein Problem aus der Version 1.5-experimental2 behoben, bei der die Projektions-DLL nicht generiert wurde. Weitere Informationen finden Sie im GitHub-Issue #4152.
• Es wurde ein Problem behoben, bei dem die Schaltfläche mit den Auslassungspunkten im Popup "Textformatierung" der RichEditBox Liste der Aktionen nicht ordnungsgemäß angezeigt wurde. Weitere Informationen finden Sie im GitHub-Issue #9140.
• Es wurde ein Problem behoben, bei dem die ListView Tastenkombinationen nicht ordnungsgemäß behandelt wurden. Weitere Informationen finden Sie im GitHub-Issue #8063.
• Ein Zugriffsverletzungsproblem mit der Verwendung AccessKey zum Schließen eines Fensters wurde behoben. Weitere Informationen finden Sie im GitHub-Issue #8648.
• Es wurde ein Absturz behoben, wenn ein AccessKey zum Schließen eines Fensters verwendet wurde. Weitere Informationen finden Sie im GitHub-Issue #9002.
• Es wurde ein Problem behoben, das sich auf die Textausrichtung in einem MenuFlyoutItem innerhalb eines MenuBar auswirkt. Weitere Informationen finden Sie im GitHub-Issue #8755.
• Es wurde ein Problem behoben, bei dem hervorgehobener Text nach einem Rechtsklick nicht hervorgehoben blieb. Weitere Informationen finden Sie im GitHub-Issue #1801.
• Es wurde ein Problem behoben, das dazu führte, dass inaktive Fenster beim Schließen der App abstürzten. Weitere Informationen finden Sie im GitHub-Issue #8913.
• Es wurde ein Problem behoben, das dazu führen konnte, dass Anwendungen hängen blieben, wenn mit der mittleren Maustaste gescrollt und unmittelbar danach mit der linken Maustaste geklickt wurde. Weitere Informationen finden Sie im GitHub-Issue #9233.
• Das Problem, das dazu führte, dass Apps beim Start abstürzen, wenn sie eine benutzerdefinierte NavigationViewItem verwenden, wurde behoben. Weitere Informationen finden Sie im GitHub-Issue #8814.
• Das Problem mit NavigationView wurde behoben, bei dem die Schaltfläche mit den Auslassungspunkten fälschlicherweise einen Fehler generierte. Weitere Informationen finden Sie im GitHub-Issue #8380.
• Es wurde ein Problem behoben, bei dem SystemBackdrop nicht ordnungsgemäß in einer App mit mehreren Fenstern gerendert wurde. Weitere Informationen finden Sie im GitHub-Issue #8423.
• Ein Duplizierungsproblem beim Einfügen an den Anfang von ObservableCollection wurde behoben. Weitere Informationen finden Sie im GitHub-Issue #8370.

Version 1.4

Version 1.4.5 (1.4.240211001)

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

• Es wurde ein Problem behoben, das dazu führen konnte, dass Anwendungen hängen blieben, wenn mit dem Mausrad gescrollt und unmittelbar danach mit einer Maustaste geklickt wurde. Weitere Informationen finden Sie im GitHub-Issue #9233.
• Ein Problem behoben, bei dem Ressourcen dupliziert wurden, wenn auf eine Kette von NuGet-Paketen verwiesen wurde. Weitere Informationen finden Sie im GitHub-Issue #8857.
• Es wurden mehrere BreadcrumbBar Probleme behoben, insbesondere ein Speicherverlust, ein Absturz, der durch ein leeres Auslassungspunkte-Menü und ein im Fenster falsch eingeschränktes Auslassungspunkte-Menü verursacht werden konnte.
• Es wurde ein potenzieller Absturz beim Herunterfahren behoben, der beim Freigeben von Grafikressourcen auftreten konnte.

Version 1.4.4 (1.4.231219000)

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

• Ein WinUI 3 Diagnose Sicherheitsproblem wurde behoben.
• Es wurde ein Eingabeproblem behoben, bei dem das Kennwortfeld die Bildschirmtastatur beim Aktivieren per Touch nicht angezeigt hat. Weitere Informationen finden Sie im GitHub-Issue #8946.
• Ein Problem wurde behoben, durch das die Microsoft.UI.Xaml.Controls.dll Dateigröße unerwartet vergrößert wurde.
• Ein CommandBarFlyout Problem wurde behoben, das beim Festlegen des Fokus zu Abstürzen führen konnte.
• Unterstützung des Windows App SDK für .NET 8 RID-spezifische Ressourcenbehandlung aktualisiert.
• Es wurde ein Problem behoben, durch das einige Swapchains falsch positioniert oder gestreckt wurden.

Version 1.4.3 (1.4.231115000)

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

• Es wurde ein Problem behoben, bei dem ein Menü für kurze Zeit ohne Hintergrund angezeigt werden konnte.
• Es wurde ein Absturz behoben, der in bestimmten Szenarien mit mehreren Monitoren auftreten konnte.
• Es wurde ein Problem behoben, bei dem ein Kontextmenü außerhalb des Bildschirms angezeigt werden konnte.
• Es wurde ein Problem mit Fensterformatvorlagen und dem Verhalten beim Maximieren behoben. Weitere Informationen finden Sie im GitHub-Issue #8996.
• Es wurde ein Problem mit Islands behoben, bei dem der Fokus unerwartet von einem anderen Steuerelement übernommen werden konnte.
• Es wurde ein Problem mit der Reihenfolge der Registerkarten in NavigationView behoben.
• Es wurde ein Renderingproblem behoben, bei dem am oberen Rand der Titelleiste möglicherweise ein weißer Balken sichtbar war. Weitere Informationen finden Sie im GitHub-Issue #8947.
• Verschiedene Leistungskorrekturen.

Version 1.4.2 (1.4.231008000)

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

• Es wurde ein Absturzproblem in explorer.exe behoben, das durch übermäßige Speicher- und Objektzuweisung verursacht wurde.
• Es wurde ein Problem mit der Interaktion auf der Titelleiste behoben, durch das die Zurück-Schaltfläche nicht ordnungsgemäß funktionierte.
• Es wurde ein Problem behoben, das dazu führte, dass eine Warnung für eine Quelldatei mehrmals generiert wurde.
• Es wurde ein Problem behoben, das sich auf die Leistung des Kontextmenüs auswirkt.
• Es wurde ein LNK-Verknüpfungsproblem behoben, durch das die EXE-Zieldatei immer auf denselben Speicherort für Pakete im Ordner „WindowsApps“ verweist.
• Ein DWriteCore-Problem wurde behoben, welches das ordnungsgemäße Rendern von indischen Text in bestimmten Schriftarten beeinflusste.
• Es wurde ein Problem in einer Listenansicht behoben, durch das die richtige Tastaturnavigation zu und von geschachtelten ausgewählten Elementen mit TAB/ UMSCHALT+TABverhindert wurde.
• Es wurde ein Problem behoben, durch welches das Scrollen von ComboBox-Elementen durch Toucheingabe nach dem Erweitern des ComboBox-Steuerelements ein zweites Mal abgebrochen wurde. Weitere Informationen finden Sie im GitHub-Issue #8831.
• Es wurde ein Problem behoben, bei dem WinAppSDK-Pakete nicht die lokalisierten WinUI-Ressourcen für einige Sprachen enthielten.
• Es wurde eine Inkonsistenz zwischen der Anzeige der bevorzugten Sprache eines Benutzers im Datei-Explorer und XAML behoben.
• Es wurde ein Handwerksproblem im Datei-Explorer behoben, das dazu führte, dass unter der aktiven Registerkarte eine dünne Linie angezeigt wurde.
• Es wurde ein Problem behoben, bei dem einige vom Framework bereitgestellte Zugriffstasten nicht ordnungsgemäß lokalisiert wurden. Weitere Informationen finden Sie im GitHub-Issue #2023.
• Es wurde ein Problem mit RepeatButton-Steuerelementen behoben, die beim Tippen wiederholt scrollen.
• Die EXE-Datei des WinAppSDK-Installationsprogramms wurde so korrigiert, dass sie die richtigen Informationen zur Ressourcenversion enthält.

Version 1.4.1 (1.4.230913002)

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

• Leistungsprobleme wurden behoben, um die Zeit bis zum ersten Frame zu verbessern.
• Ein Problem wurde behoben, bei dem Menüs RequestedTheme nicht respektiert haben. Beispielsweise konnte war dieses Problem zu weißem Text auf einem weißen Hintergrund führen. Weitere Informationen finden Sie im GitHub-Issue #8756.
• Ein Problem wurde behoben, das dazu führte, dass Acrylhintergründe in einigen Menüs manchmal vollständig transparent wurden.
• Ein Problem wurde behoben, bei dem XAML manchmal dazu führte, dass Windows das Desktop-Hintergrundbild unnötig neu generiert hat.
• Die Unterstützung für TabNavigation = Local und TabNavigation = Cycle für ListView und GridView wurde korrigiert, so dass jetzt das Navigieren zwischen Kopfzeilen und Elementen mit der Tabulator-Taste zusätzlich zu Pfeiltasten möglich ist.
• Einige auffällige Ausnahmen beim Schließen einer QuickInfo wurden behoben. Weitere Informationen finden Sie im GitHub-Issue #8699.

Version 1.4

In den folgenden Abschnitten werden neue und aktualisierte Features und bekannte Probleme für Version 1.4 beschrieben.

In einer vorhandenen Windows App SDK 1.3-App können Sie Ihr NuGet-Paket auf 1.4.230822000 aktualisieren (weitere Informationen finden Sie im Abschnitt Aktualisieren eines Pakets in Installieren und Verwalten von Paketen in Visual Studio mit dem NuGet-Paket-Manager).

Die aktualisierten Runtime- und MSIX-Pakete finden Sie unter Downloads für das Windows App SDK.

Benutzerdefinierte Titelleiste + AppWindow-Titelleistenzusammenführung

Die benutzerdefinierte WinUI 3-Titelleiste verwendet die AppWindow-Titelleistenimplementierung zusammen mit den NonClientInputPointerSource-APIs unter der Haube im Windows App SDK 1.4. Daher verhalten sich jetzt beide Titelleisten-Implementierungen gleich, mit den gleichen Funktionen und Einschränkungen. Dies ist in allen unterstützten Fällen vollständig abwärtskompatibel – jede App mit einer benutzerdefinierten Titelleiste verhält sich wie bisher. Aber für WinUI 3-Entwickler, die noch keine Erfahrung mit benutzerdefinierten Titelleisten haben, ist es jetzt einfacher, diese zu verstehen und zu verwenden, indem sie die Vorteile dieser neuen Funktionen nutzen:

• Ein besseres Standardszenario, bei dem der Entwickler kein spezielles Titelleistenelement definiert (als Ersatz für die Fallback-Titelleiste von WinUI 2)
• Unterschiedliche Ziehbereiche in der Titelleiste, mit denen Sie mehrere Ziehbereiche erstellen und anklickbare Steuerelemente auf einem beliebigen Teil des Nicht-Client-Bereichs (Titelleistenbereich) platzieren können
• App-weite verschiebbare Bereiche, die überall in der App platziert werden können oder die gesamte App verschiebbar machen
• Bessere Design-Unterstützung, die das ressourcenbasierte Design ersetzt
  • Da die Ziehbereiche transparent sind, passen sie sich jedes Mal dem Design der App an
• Weitere Anpassungen: Ausblenden der Schaltflächen Min, Max und Schließen; Platzieren von Systemsymbolen in der Titelleiste; oder Einrichten verschiedener Bereiche als Untertitel-Schließen, die NCHITTEST-Antworten erhalten
• Mehr Entwicklungsfreiheit, mit der Sie die APIs für die AppWindow-Titelleiste kombinieren können. Verwenden Sie z. B. WinUI 3-APIs auf höherer Ebene für die meisten Szenarien und nutzen Sie die AppWindow-APIs für die Steuerung auf niedrigerer Ebene.

Widgets-Updates

Es wurden drei neue Schnittstellen für Widgetanbieter hinzugefügt: IWidgetProvider2, IWidgetProviderAnalytics, und IWidgetProviderErrors. Mit IWidgetProvider2 können Anbieter auf die vom Benutzer aufgerufene Aktion Anpassen reagieren. Dies ist identisch mit der Funktionalität, die für eigene Widgets verfügbar ist. Mit den Schnittstellen IWidgetProviderAnalytics und IWidgetProviderErrors können Anbieter Telemetriedaten für ihre Widgets sammeln. Die jeweiligen Widgetanbieter erhalten so Analyse- und Fehlerereignisse von Widgets. Die Klassen WidgetCustomizationRequestedArgs, WidgetAnalyticsInfoReportedArgs und WidgetErrorInfoReportedArgs werden verwendet, um relevante Informationen zur Unterstützung neuer Funktionen zu vermitteln.

XAML-Inseln nicht mehr nur experimentell

XAML-Inseln und die zugrunde liegende ContentIslands-Plattform sind nicht mehr nur experimentell.

• Derzeit werden XAML-Inseln nur für die Verwendung in C++-Apps getestet. Diese Version enthält keine praktischen Wrapperelemente für die Verwendung in WPF oder WinForms.
• DesktopWindowXamlSource und verwandte Typen wurden im Microsoft.UI.Xaml.Hosting-Namespace für XAML-Inseln hinzugefügt. XamlRoot.ContentIslandEnvironment wurde hinzugefügt, um den Zugriff auf die zugrunde liegenden Inselinformationen für ein Element zu erleichtern.
• Viele neue Typen wurden im Microsoft.UI.Content-Namespace und im Microsoft.UI.Input-Namespace als zugrunde liegende Unterstützung für XAML-Inseln oder für die Verwendung dieser ContentIslands-Funktionalität ohne XAML eingeführt.
• Im Namespace „Microsoft.UI.Input.DragDrop“ für Inselszenarien wurde ein neuer DragDropManager (plus verwandter Typen) hinzugefügt.

ItemsView

Wir führen ein neues Listensteuerelement ein, das als ItemsView bezeichnet wird und eine entsprechende konkrete ItemContainer-Klasse. ItemContainer ist ein einfacher Container mit integrierten Auswahlzuständen und visuellen Elementen, der die gewünschten Inhalte problemlos umschließen und zusammen mit ItemsView für ein Szenario mit Sammlungssteuerung verwendet werden kann.

• Das neue Steuerelement ItemsView zeigt eine Datensammlung an. ItemsView ähnelt den Steuerelementen ListView und GridView, wird jedoch mit den Komponenten ItemsRepeater, ScrollView, ItemContainer und ItemCollectionTransitionProvider erstellt. Es bietet die einzigartige Möglichkeit, benutzerdefinierte Layout- oder ItemCollectionTransitionProvider-Implementierungen einzubinden. Ein weiterer wichtiger Vorteil ist die Möglichkeit, das Layout während der Verwendung zu wechseln und gleichzeitig die Auswahl von Elementen beizubehalten. Das innere ScrollView-Steuerelement bietet außerdem Funktionen, die in dem in ListView/GridView integrierten ScrollViewer-Steuerelement nicht verfügbar sind, wie z. B. die Möglichkeit, die Animation bei programmgesteuerten Bildläufen zu steuern.
  • Mit der neuen ItemTransitionProvider-Eigenschaft des ItemsRepeater (und dem neuen Steuerelement ItemsView) können Sie ein ItemCollectionTransitionProvider-Objekt zum Steuern von Übergangsanimationen für dieses Steuerelement angeben. Außerdem wurde eine CreateDefaultItemTransitionProvider-Methode zu Layout hinzugefügt, die es einem Layoutobjekt ermöglicht, einen integrierten Fallbackübergang bereitzustellen, wenn Sie für das ItemsView-Steuerelement nicht explizit einen angeben.
  • Eine neue IndexBasedLayoutOrientation-Eigenschaft für Layout, bei der die Layout-Ausrichtung von Objekten, falls vorhanden, auf ihrem Index in der Quellensammlung basiert. Der Standardwert ist IndexBasedLayoutOrientation.None. Benutzerdefinierte Layouts legen diese Eigenschaft durch Aufrufen der neuen (geschützten) SetIndexBasedLayoutOrientation-Methode fest.
  • Eine neue VisibleRect-Eigenschaft auf VirtualizingLayoutContext zum Abrufen des sichtbaren Viewport-Rechtecks innerhalb des FrameworkElement, das dem Layout zugeordnet ist. Die geschützte virtuelle Methode VirtualizingLayoutContext.VisibleRectCore kann überschrieben werden, um den Wert bereitzustellen, der von der Eigenschaft VisibleRect zurückgegeben wird.
• Die neue Klasse LinedFlowLayout wird in der Regel verwendet, um die Elemente des Auflistungssteuerelements ItemsView zu gestalten. Sie ist besonders nützlich, eine Sammlung von Bildern anzuzeigen. Dabei werden die Elemente von links nach rechts und von oben nach unten in gleich hohen Zeilen angeordnet. Die Bilder füllen eine horizontale Zeile und gehen dann in die nächste Zeile über. Bilder können am linken und rechten Rand abgeschnitten werden, damit sie in eine Zeile passen. Sie können auch horizontal erweitert und am oberen und unteren Rand abgeschnitten werden, um eine Zeile zu füllen, wenn der Dehnungsmodus verwendet wird.

Neue Funktionen aus dem gesamten WinAppSDK

• Eine neue ThemeSettings-Klasse, mit der Win32 WinRT-Apps erkennen können, dass sich die Einstellung des Systems für hohen Kontrast geändert hat, ähnlich der UWP-Klasse AccessibilitySettings. Weitere Informationen finden Sie in der ThemeSettings-API-Spezifikation auf GitHub.
• AccessKeyManager.EnterDisplayMode ist eine neue Methode zum Anzeigen von Tastenkombinationen für das aktuelle fokussierte Element eines bereitgestellten Stamms. Tastenkombinationen befinden sich im „Anzeigemodus“, wenn eine Tastenkombination zum Aufrufen eines Befehls angezeigt wird, z. B. wenn Sie in Paint die Alt-Taste drücken, um anzuzeigen, welche Tasten welchen Steuerelementen entsprechen. Diese Methode ermöglicht die programmgesteuerte Anzeige des Anzeigemodus.
• Application.ResourceManagerRequested bietet einen Mechanismus zur Bereitstellung eines anderen IResourceManager zur Auflösung von Ressourcen-URIs für Szenarien, in denen der Standard-ResourceManager nicht funktioniert. Weitere Informationen finden Sie in der Application.ResourceManagerRequested-API-Spezifikation auf GitHub.
• Die Version des WebView2 SDK wurde von 1661.34 auf 1823.32 aktualisiert.
• Popup/FlyoutBase.IsConstrainedToRootBounds = false wird jetzt unterstützt, sodass ein Popup-/Flyout außerhalb der Grenzen des übergeordneten Fensters erweitert werden kann. Zu diesen Typen wurde eine SystemBackdrop-Eigenschaft hinzugefügt, um Acryl in diesen nicht eingeschränkten Popups zu unterstützen. Diese Funktion wird in Menüs standardmäßig verwendet, um Acryl zu verwenden.
• Closed, FrameworkClosed und IsClosed wurden zu DesktopAcrylicController und MicaController hinzugefügt, um die Abwicklung des Herunterfahrens von Objekten/Threads zu verbessern.
• DesktopAcrylicController.Kind kann jetzt so eingestellt werden, dass Sie zwischen einigen Standard-Acryl-Darstellungen wählen können.
• DispatcherQueue verfügt über einige neue Ereignisse und Hilfsprogramme, um das Herunterfahren besser zu koordinieren und für Anwendungen, die Inseln verwenden, einfach eine standardmäßig unterstützte Ereignisschleife auszuführen.
• Im Namespace „Microsoft.UI.Input“ kann InputNonClientPointerSource für benutzerdefinierte Titelleistenszenarien verwendet werden, um Bereiche außerhalb des Clientbereichs zu definieren. Code kann für entsprechende Ereignisse wie Zeigen und Klicken auf Ereignisse in diesen Regionen registriert werden.
• AppWindow hat einige neue Hilfsprogramme, um eine DispatcherQueue zu erhalten und sich mit ihr zu verknüpfen.
• Mit dem neuen TreeView.SelectionChanged-Ereignis können Entwickler*innen reagieren, wenn Benutzer*innen oder der Code-Behind die Menge der ausgewählten Knoten im TreeView-Steuerelement ändern.
• Das neue ScrollView-Steuerelement bietet eine neue Alternative zu ScrollViewer. Dieses neue Steuerelement ist stark im Verhalten und der API an dem vorhandenen ScrollViewer-Steuerelement ausgerichtet. Es basiert jedoch auf InteractionTracker, hat neue Features wie animationsgesteuerte Ansichtsänderungen und ist auch darauf ausgelegt, die volle Funktionalität von ItemsRepeater sicherzustellen. Weitere Informationen finden Sie unter A more flexible ScrollViewer · Issue #108 · microsoft/microsoft-ui-xaml (github.com). Verschiedene neue Typen, einschließlich ScrollPresenter, sind Teil des Gesamtmodells von ScrollView.
• Das neue AnnotatedScrollBar-Steuerelement erweitert die Funktionalität einer regulären Bildlaufleiste, indem es eine einfache Möglichkeit zum Navigieren durch eine große Sammlung von Elementen ermöglicht. Dies wird durch eine klickbare Leiste mit Bezeichnungen erreicht, die als Markierungen fungieren. Es ermöglicht auch ein genaueres Verständnis des bildlauffähigen Inhalts, indem eine QuickInfo angezeigt wird, wenn Sie auf die klickbare Leiste zeigen.

Bekannte Probleme

• Wenn Sie ExtendsContentIntoTitleBar = true verwenden, zeigen Klicks in die obere linke Ecke des Fensters standardmäßig immer das Systemfenstermenü an (Minimieren/Schließen/usw.), anstatt die Zeigereingaben auf den Inhalt des Fensters zuzulassen. Dies bedeutet beispielsweise, dass eine Schaltfläche „Zurück“ in diesem Bereich der Titelleiste nicht funktionieren wird. Eine Problemumgehung für dieses Problem besteht darin, im AppWindow-Fenster AppWindow.TitleBar.IconShowOptions = Microsoft.UI.Windowing.IconShowOptions.HideIconAndSystemMenu festzulegen.
• Beim Ausblenden von ShouldConstrainToRootBounds="False"-Popups/Flyouts gibt es einige neue zusammenhängende Ausnahmen. Dazu gehört das Ausblenden von QuickInfos, wie hier beschrieben: Dismissing a tooltip throws 4 native exceptions · Issue #8699 · microsoft/microsoft-ui-xaml (github.com)
• In 1.4 werden die Untertitel-Schaltflächen Min/Max/Schließen für ExtendsContentIntoTitleBar = true jetzt von AppWindow anstelle von XAML gezeichnet. Das ist beabsichtigt, aber es kann sich auf Anwendungen auswirken, die die internen XAML-Stile überschreiben, um diese Schaltflächen auszublenden oder zusätzlich anzupassen, wie z. B. in diesem Bericht: Cannot hide caption button on titlebar · Issue #8705 · microsoft/microsoft-ui-xaml (github.com)
• In .NET 8 wurde die Handhabung des Laufzeitbezeichnerdiagramms grundlegend geändert: [Breaking change]: Projects targeting .NET 8 and higher will by default use a smaller, portable RID graph. · Issue #36527 · dotnet/docs (github.com). Aufgrund dieses Problems und weil .NET 8 noch nicht offiziell veröffentlicht wurde, unterstützt das Windows App SDK 1.4 .NET 8 offiziell nicht. Wenn Sie dennoch die Vorabversion von .NET 8 mit dieser Version des App SDK verwenden möchten, empfehlen wir die folgenden Schritte:
  • Das Festlegen von UseRidGraph auf true wird empfohlen. Außerdem müssen Sie die <RuntimeIdentifiers>-Eigenschaft in der .csproj-Datei auf <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers> aktualisieren sowie jede Propeties\*pubxml-Datei so aktualisieren, dass sie win10 zu win in der <RuntimeIdentifier>-Eigenschaft ändert (z. B. <RuntimeIdentifier>win-x86</RuntimeIdentifier>).
• Mit Windows App SDK 1.4 wurde das Ziel GenerateDeploymentManagerCS in Microsoft.WindowsAppSDK.DeploymentManager.CS.targets zu GenerateBootstrapCS umbenannt.
• MenuFlyout-Hintergrund verwendet nicht das angeforderte Design der Anwendung:
  • Der Text von MenuFlyoutItem wird nicht mit dem Systemthema synchronisiert. · Issue #8678 · microsoft/microsoft-ui-xaml (github.com)
  • 1.4 Vorschau: Flyout-Hintergrundthema wird vom Systemthema und nicht vom zugehörigen Element abgeleitet - Issue #8756 - microsoft/microsoft-ui-xaml (github.com)

Programmfehlerbehebung

• Es wurde ein Problem behoben, bei dem das Aufrufen der Microsoft.Windows.AppLifecycle.AppInstance.Restart("")-API dazu führte, dass entpackte Apps abstürzten. Weitere Informationen finden Sie im GitHub-Issue #2792.
• Es wurde ein Absturzproblem des Installers behoben, das in 1.4-experimental1 eingeführt wurde. Weitere Informationen finden Sie im GitHub-Issue #3760.
• Es wurde ein Problem behoben, bei dem durchgestrichener Text in einem TextBlock nicht ordnungsgemäß entfernt wurde. Weitere Informationen finden Sie im GitHub-Issue #1093.
• Es wurde ein Problem behoben, durch zu falscher UMSCHALT+ TAB-Navigation in einem Panel führte, bei dem TabFocusNavigation auf „Einmal“ festgelegt ist. Weitere Informationen finden Sie im GitHub-Issue #1363.
• Es wurde ein Problem in C++/WinRT behoben, das verhinderte, dass {x:Bind} mit einer Eigenschaft eines benannten XAML-Steuerelements ordnungsgemäß funktionierte. Weitere Informationen finden Sie im GitHub-Issue #2721.
• Es wurde ein AccessViolation-Laufzeitproblem in WinUI-Desktop-Apps behoben, das durch die Einstellung DebugSettings.EnableFrameRateCounter = trueverursacht wurden. Weitere Informationen finden Sie im GitHub-Issue #2835.
• Es wurde ein Problem behoben, bei dem in XamlTypeInfo.g.cpp keine erforderlichen Header enthalten waren. Weitere Informationen finden Sie im GitHub-Issue #4907.
• Es wurde ein Absturzproblem behoben, das durch gleichzeitige Multitouch- und Mauseingabe verursacht wurde. Weitere Informationen finden Sie im GitHub-Issue #7622.
• Es wurde ein Problem behoben, das verhinderte, dass ein aktives WinUI 3-Anwendungsfenster gescrollt wurde, wenn die Systemeinstellung zur Deaktivierung des Bildlaufs inaktiver Fenster beim Mausover aktiv war. Weitere Informationen finden Sie im GitHub-Issue #8764.
• Ein Absturz beim Versuch, MediaPlayerElement als Unterklasse zu verwenden, wurde behoben.
• Einige Absturz- und Speicherverluste in TreeView wurden behoben.
• Es wurde ein Problem behoben, bei dem die App hängen blieb, wenn für die Navigation in RadioButtons die Tastatur verwendet wurde.
• Es wurde ein Absturz behoben, der auftrat, wenn für die Navigation in PipsPager die Tastatur verwendet wurde.
• Der Inhalt von WebView2 skaliert jetzt mit der Einstellung „Textgröße“ in der App Einstellungen.
• Es wurde ein Absturz behoben, der auftreten konnte, wenn Animationen liefen, während der Bildschirm ausgeschaltet war.
• Ein in 1.3 eingeführtes Leistungsproblem wurde behoben, das beim ersten Layout/Rendering einen Overhead von ~10 % verursachte.

Version 1.3

Version 1.3.3 (1.3.230724000)

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

• Es wurde ein Problem behoben, bei dem die Maus manchmal nicht mehr funktionierte, wenn ein Dialogfeld geschlossen wurde.
• Es wurde ein Problem bei der Bereitstellung behoben, das die Installation von Anwendungen verhinderte, weil die Paketversionen auf dem System nicht übereinstimmten. Weitere Informationen finden Sie im GitHub-Problem #3740.
• Es wurde ein Problem mit der Positionierung des Kontextmenüs in Windows App SDK 1.3 behoben.
• Es wurde ein Problem behoben, das dazu führte, dass einige WinUI3-Apps in bestimmten Situationen abstürzten, wenn die App geschlossen wurde, weil XAML sich zu früh beendet hat.
• Es wurde ein Problem behoben, bei dem die Schriftsymbole in Sprachen mit Rechts-nach-Links-Ausrichtung nicht richtig gespiegelt wurden. Weitere Informationen finden Sie im GitHub-Problem #7661.
• Es wurde ein Problem behoben, das zum Absturz einer App beim Herunterfahren führte, wenn Ressourcen in einer falschen Reihenfolge heruntergefahren wurden. Weitere Informationen finden Sie im GitHub-Problem #7924.

Version 1.3.2 (1.3.230602002)

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

• Absturz behoben, der beim Festlegen eines geschützten Cursors auftrat.
• Leistungsproblem in XamlMetadataProvider behoben, das während des App-Starts auftrat. Weitere Informationen finden Sie im GitHub-Problem #8281.
• Problem mit Links und Toucheingaben in RichTextBlock behoben. Weitere Informationen finden Sie im GitHub-Problem #6513.
• Problem mit Scrollen und Touchpads in WebView2 wurde behoben. Weitere Informationen finden Sie im GitHub-Problem #7772.
• Problem behoben, das dazu führte, dass ein Update des Windows App SDK manchmal einen Neustart von Visual Studio erforderte. Weitere Informationen finden Sie im GitHub-Problem #3554.
• Störende Ausnahme beim Herunterfahren bei der Ausführung in einem Debugger behoben.

Version 1.3.1 (1.3.230502000)

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

• Ein Problem wurde behoben, das zum Absturz von Apps führte, wenn SystemBackdrop festgelegt wurde und der Inhalt NULL war. Weitere Informationen finden Sie im GitHub-Issue #8416.
• Ein Problem wurde behoben, das zum Absturz von Apps führte, wenn der Fenstertitel in XAML festgelegt wurde – eine neue Funktion, die in 1.3.0 hinzugefügt wurde. Weitere Informationen finden Sie im GitHub-Issue #3689.
• Ein Problem wurde behoben, bei dem ein Fenster fälschlicherweise den Fokus erhielt, wenn der Inhalt sich änderte.
• Es wurde ein Problem beim Erstellen von C++-Projekten mit den WinAppSDK 1.3-Projektvorlagen behoben.
• Aktualisierte Vorlagen im Visual Studio Marketplace

Version 1.3

In den folgenden Abschnitten werden neue und aktualisierte Features und bekannte Probleme für Version 1.3 beschrieben.

In einer vorhandenen Windows App SDK 1.2-App können Sie Ihr NuGet-Paket auf 1.3.230331000 aktualisieren (siehe Abschnitt Aktualisieren eines Pakets in Installieren und Verwalten von Paketen in Visual Studio mit dem NuGet-Paket-Manager).

Die aktualisierten Runtime- und MSIX-Pakete finden Sie unter Downloads für das Windows App SDK.

XAML-Hintergrund-APIs

Mit in das XAML-Fenster integrierten Eigenschaften können Mica- und Background Acrylic-Hintergründe jetzt einfacher in Ihrer WinUI 3-App verwendet werden. Informationen zu den XAML-Hintergrundeigenschaften finden Sie in der API-Dokumentation zu SystemBackdrop und MicaBackdrop.

public MainWindow()
{
    this.InitializeComponent();

    this.SystemBackdrop = new MicaBackdrop();
}

Window.AppWindow

Durch Ersetzen mehrerer Zeilen mit Codebausteinen können Sie AppWindow-APIs jetzt über direkt aus einem FensterWindow.AppWindow verwenden.

Neue Features aus WinAppSDK

• ApplicationModel.DynamicDependency: PackageDependency.PackageGraphRevisionId ersetzt die veraltete MddGetGenerationId-Funktion.
• Umgebungs-Manager: EnvironmentManager.AreChangesTracked informiert Sie darüber, ob Änderungen am Umgebungs-Manager in Ihrer Anwendung nachverfolgt werden können.
• Ein neues Ereignis, DebugSettings.XamlResourceReferenceFailed, wird jetzt ausgelöst, wenn ein referenzierter Static-/ThemeResource-Lookup nicht aufgelöst werden kann. Dieses Ereignis gibt Zugriff auf eine Ablaufverfolgung, die angibt, wo das Framework nach diesem Schlüssel gesucht hat, damit Sie Fehler bei Static- und ThemeResource-Lookups besser debuggen können. Weitere Informationen finden Sie in der API-Spezifikation Tracing XAML resource reference lookup failures auf GitHub.

Weitere Updates

• Informationen zu weiteren Problemen, die in diesem Release behoben wurden, finden Sie bei den Milestones für WinAppSDK 1.3 auf der GitHub-Seite WinAppSDK.
• Informationen zu weiteren Problemen, die in diesem Release behoben wurden, finden Sie bei den Milestones für WinUI 3 in WinAppSDK 1.3 auf der GitHub-Seite microsoft-ui-xaml.
• Mit dem neuesten experimentellen VSIX-Paket können Sie Ihre App jetzt über das Visual Studio-Menü anstatt in Ihrer Projektdatei von der nicht gepackten in die gepackte Version konvertieren.

Bekanntes Problem

Aufgrund einer kürzlich erfolgten Änderung am XAML-Compiler kann bei einem vorhandenen Projekt, für das ein Upgrade auf Version 1.3 ausgeführt wird, in Visual Studio ein Buildfehler wie der folgende auftreten:

> C:\Users\user\\.nuget\packages\microsoft.windowsappsdk\\**1.3.230331000**\buildTransitive\Microsoft.UI.Xaml.Markup.Compiler.interop.targets(537,17): error MSB4064: The "PrecompiledHeaderFile" parameter is not supported by the "CompileXaml" task loaded from assembly: Microsoft.UI.Xaml.Markup.Compiler, Version=1.0.0.0, Culture=neutral, PublicKeyToken=de31ebe4ad15742b from the path: C:\Users\user\\.nuget\packages\microsoft.windowsappsdk\\**1.2.230118.102**\tools\net472\Microsoft.UI.Xaml.Markup.Compiler.dll. Verify that the parameter exists on the task, the <UsingTask> points to the correct assembly, and it is a settable public instance property.

Dies wird dadurch verursacht, dass Visual Studio eine zwischengespeicherte XAML-Compilertask-DLL aus Version 1.2 verwendet, sie aber mit inkompatibler MSBuild-Logik aus Version 1.3 verarbeitet, wie im obigen Fehlertext zu sehen. Die Problemumgehung besteht darin, Visual Studio zu schließen, neu zu starten und die Projektmappe neu zu laden.

Version 1.2

Version 1.2.5 (1.2.230313.1)

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

• Ein Problem wurde behoben, das dazu führte, dass Apps während des Herunterfahrens von Composition abstürzten.
• Ein Problem wurde behoben, das dazu führte, dass Apps Animationen auch dann fortsetzten, wenn der Bildschirm ausgeschaltet war.
• Ein Problem wurde behoben, das zu Fehlern bei Maus- und Toucheingaben in WebView2 führte, wenn Maus- und Tastatureingaben gleichzeitig erfolgten. Weitere Informationen finden Sie im GitHub-Issue #3266.

Version 1.2.4 (1.2.230217.4)

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

• Ein Problem wurde behoben, das dazu führte, dass eigenständige Apps keine UAC-Einstellungen festlegen konnten. Weitere Informationen finden Sie im GitHub-Issue #3376.
• Ein Problem wurde behoben, das dazu führte, dass Pushbenachrichtigungen bei PushNotificationChannel::ExpirationTime eine ungenaue Ablaufzeit zurückgaben. Weitere Informationen finden Sie im GitHub-Issue #3300.
• Ein Problem wurde behoben, das dazu führte, dass negative Zahlen als „ungültig“ betrachtet wurden, wenn ein double-Wert als Parameter an eine x:Bind-Funktion übergeben wurde.
• Mehrere Fehlerbehebungen wurden zum Aktualisieren von WinUI VSIX vorgenommen. Hierzu gehören die Vereinfachung der Projektvorlage dipAwareness in app.manifest, das Entfernen der UWP-Vorlagen, das Aktualisieren lokalisierter Ressourcendateien, das Hinzufügen der Telefon-ID zum Aufheben der Blockierung der Storeübermittlung und das Entfernen von Copyrighthinweis und Lizenz. Weitere Informationen finden Sie in den GitHub-Issues #5659, #3205, #3323, #3322 und #3143.

Version 1.2.3 (1.2.230118.102)

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

• Ein Problem wurde behoben, das dazu führte, dass WinUI 3-Apps abstürzten, wenn mehrere Fenster geschlossen wurden.
• Ein Problem wurde behoben, das zu einem Absturz beim Schließen der App führte, wenn zwei oder mehr Verweise auf die ThreadPoolTimer-Schnittstelle aufgerufen wurden. Weitere Informationen finden Sie in den GitHub-Issues #7260 und #7239.
• Ein Problem wurde behoben, das dazu führte, dass alle MSIX-Einzelprojekt-Apps als vollständig vertrauenswürdig ausgeführt wurden. Weitere Informationen finden Sie im GitHub-Issue #7766.

Version 1.2.2 (1.2.221209.1)

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

• Ein Problem wurde behoben, das dazu führte, dass Store- und Querladepakete (z. B. aus Installationsprogramm, NuGet und Bootstrapper) nicht installiert wurden, wenn das jeweils andere bereits installiert war. Weitere Informationen finden Sie im GitHub-Issue #3168.
• Ein Problem wurde behoben, das zu fehlenden Elastizitätseffekten und Animationskurven beim Scrollen mit einem Touchpad führte. Weitere Informationen finden Sie im GitHub-Issue #7874.
• Es wurde ein Problem in ListView behoben, das zu Arbeitsspeicherverlusten führte.
• Ein Problem wurde behoben, das dazu führte, dass die Button-Vorlage die Foreground-Eigenschaft nach dem Zeigen mit der Maus nicht beachtete. Weitere Informationen finden Sie im GitHub-Issue #7208.
• Ein Problem wurde behoben, das zu einer unnötigen Ausnahme führte, wenn in einem MediaElement kein MediaPlaybackItem vorhanden war.
• Ein Problem wurde behoben, das dazu führte, dass im MediaPlayerElement bei Inhaltsübergängen ein weißer Rahmen angezeigt wurde.
• Es wurden weitere Probleme behoben, die dazu führten, dass App.UnhandledException Ausnahmen von anderen Threads nicht abfing. Weitere Informationen finden Sie in den GitHub-Issues #1259 und #5221.

Version 1.2.1 (1.2.221116.1)

Dies ist ein Wartungsrelease des Windows App SDK, das eine wichtige Fehlerbehebung für das Release 1.2 enthält.

Ein Problem wurde behoben, das beim Starten in C++-WinUI 3-Apps einen Absturz verursachte, wenn ein WebView2- oder TextBox-Steuerelement hinzugefügt wurde. Weitere Informationen finden Sie in den GitHub-Issues #7911 und #3117.

Version 1.2

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

Hinweis

Visual Studio 2019 und .NET 5 werden für das Kompilieren von C#-Apps nicht mehr unterstützt (siehe Windows App SDK 1.2 moving to C# WinRT 2.0). Sie benötigen Visual Studio 2022 und eine der folgenden .NET SDK-Versionen: 6.0.401 (oder höher), 6.0.304, 6.0.109. Nach der Veröffentlichung unterstützt WinAppSDK 1.2 auch .NET 7.

Zum Aktualisieren Ihrer .NET SDK-Version installieren Sie die neueste Version von Visual Studio 2022, oder besuchen Sie die Download-Website für .NET. Wenn Sie Ihr NuGet-Paket ohne die erforderliche .NET SDK-Version aktualisieren, wird ein Fehler wie dieser angezeigt: Diese Version von WindowsAppSDK erfordert .NET 6 oder höher und WinRT.Runtime.dll Version 2.0 oder höher. Um das Projekt von .NET 5.0 auf .NET 6.0 zu aktualisieren, öffnen Sie die Projektdatei, und ändern Sie „TargetFramework“ zu net6.0 und „Zielbetriebssystemversion“ in den entsprechenden Wert (z. B. net6.0-windows10.0.19041.0).

Widgets von Drittanbietern in Windows

Das Widgets-Board wurde erstmals in Windows 11 eingeführt und war auf die Anzeige integrierter Widgets beschränkt. Widgets sind kleine UI-Container, die Text und Bilder auf dem Widgets-Board anzeigen, und sind mit einer auf dem Gerät installierten App verknüpft. Mit dem Windows App SDK können Drittanbieterentwickler*innen jetzt Widgets für Ihre gepackten Win32-Apps erstellen und diese lokal auf dem Widgets-Board unter Windows 11 testen.

Weitere Informationen zu Widgets finden Sie in der Übersicht über Widgets.

Zum Einstieg in die Entwicklung von Widgets für Ihre App finden Sie in der Dokumentation zur Entwicklung durch Widgetanbieter und den Grundlagen des Widgetdesigns Informationen zu Voraussetzungen sowie Anleitungen und Best Practices.

Zu den Voraussetzungen für dieses Release gehören:

• Der Entwicklermodus muss auf dem Entwicklungscomputer aktiviert sein.
• Auf dem Entwicklungscomputer wird eine Windows-Version aus dem Dev-Kanal von Windows Insider Preview (WIP) ausgeführt, die größer oder gleich 25217 ist und die Widgets-Board-Version 521.20060.1205.0 oder höher enthält.

Bekannte Einschränkungen beim Entwickeln von Widgets

• Widgets von Drittanbietern können nur lokal auf Geräten getestet werden, die für diese Vorschauversion bei WIP registriert sind.
• Widgets können nur für gepackte Win32-Apps erstellt werden. Die Unterstützung für Widgets für progressive Web-Apps (PWA) ist im Rahmen von Microsoft Edge 108 geplant.

DisplayInformation

Windows-Desktop-Apps können jetzt High Dynamic Range (HDR) und Auto Color Management (ACM) über die DisplayInformation-Klasse in WinAppSDK unterstützen. Mit der DisplayInformation-Klasse können Sie displaybezogene Informationen für eine Anwendungsansicht überwachen. Dies umfasst Ereignisse, mit denen Clients Änderungen an der Anwendungsansicht überwachen können, die sich darauf auswirken, auf welchen Displays die Ansicht angezeigt wird, sowie Änderungen an Displays, die sich auf die Anwendungsansicht auswirken können.

WinUI 3

WinUI 3-Apps können Audio- und Videodaten mit den Steuerelementen MediaPlayerElement und MediaTransportControls für die Medienwiedergabe wiedergeben. Weitere Informationen zur Verwendung von Mediensteuerelementen finden Sie unter Media Player.

WinUI 3 wurde mit den neuesten Steuerelementen, Stilen und Verhaltensweisen von WinUI 2.8 aktualisiert. Diese Updates umfassen das Hinzufügen des Steuerelements InfoBadge, Verbesserungen bei Barrierefreiheit und dem Modus mit hohem Kontrast sowie Fehlerbehebungen für verschiedene Steuerelemente. Weitere Informationen finden Sie in den Versionshinweisen für WinUI 2.7 und WinUI 2.8.

Behobene Probleme

• Material mit Acrylic-Hintergrund mit DesktopAcrylicController wird jetzt in Windows 10-Apps unterstützt. Weitere Informationen finden Sie im GitHub-Issue #7112.
• Es wurden verschiedene Probleme behoben, die zu einem Fehler beim Routing von App.UnhandledException geführt haben. Weitere Informationen finden Sie im GitHub-Issue #5221. In Bezug auf die verbleibenden Probleme sind unter den folgenden GitHub-Issues Problemumgehungen dokumentiert und werden in einem zukünftigen Release von 1.2 behoben:
  • App_UnhandledException's UnhandledExceptionEventArgs.Exception kann nur einmal abgerufen werden – should be cached
  • Do_Abi_* Event/Callback-Handler sollten Aufrufe mit RoReportUnhandledError verpacken
• Ein Problem wurde behoben, das dazu führte, dass ListView-Stile aus WinAppSDK 1.1 zurückgebildet und geändert wurden. Weitere Informationen finden Sie im GitHub-Issue #7666.
• Ein Problem wurde behoben, das dazu führte, dass eine falsche Hintergrundfarbe beim Mica-Fallback angezeigt wurde, wenn die App inaktiv war. Weitere Informationen finden Sie im GitHub-Issue #7801.

Bekannte Einschränkungen

• Beim Erstellen eines neuen WinUI 3-Projekts mit Visual Studio 2022 17.4.0 wird auf eine Vorschauversion des WinAppSDK verwiesen. Verwenden Sie den NuGet-Paket-Manager, um den Verweis auf dieses Release zu aktualisieren.
• Beim Festlegen von MediaPlayerElement.Source auf einen relativen URI (ms-appx/ms-resource) tritt in nicht gepackten Apps ein Fehler auf. Die empfohlene Problemumgehung besteht darin, den relativen ms-appx:///-URI in einen vollständig aufgelösten file:///-URI zu konvertieren.

Kürzen für Apps, die mit .NET entwickelt wurden

.NET-Entwickler können jetzt gekürzte WinAppSDK-Apps veröffentlichen. Mit CsWinRT 2.0 können die in WinAppSDK verteilten C#/WinRT-Projektionen jetzt gekürzt werden. Die Veröffentlichung Ihrer App in gekürztem Zustand kann den Speicherplatzbedarf Ihrer App verringern, indem nicht verwendeter Code aus kürzungsfähigen Binärdateien entfernt wird. Bei Apps kann auch eine Verbesserung der Startleistung festgestellt werden. Bei einer einfachen „Hallo Welt“-App haben wir eine Verbesserung von ca. 80 % beim Datenträgerspeicherplatz und eine Verbesserung von ca. 7 % bei der Startleistung festgestellt, wenn die App gekürzt veröffentlicht wurde. Beim dem WinUI-Katalog haben wir eine Verbesserung des Speicherplatzbedarfs von ca. 45 % festgestellt.

Weitere Informationen zum Aktivieren der Kürzung, Einschränkungen beim Kürzen (z. B. Reflektion für kürzungsfähige Typen) und Kürzen von Warnungen finden Sie unter Kürzen eigenständiger Bereitstellungen und ausführbarer Dateien. Entwickler*innen sollten ihre Apps nach dem Kürzen gründlich testen, um sicherzustellen, dass alles wie erwartet funktioniert. Weitere Informationen finden Sie im GitHub-Issue #2478.

Unterstützung für Visual Studio Arm64

Bereits bei Project Reunion (jetzt WinAppSDK) 0.5 konnten mit WinAppSDK entwickelte Apps auf Arm64 ausgeführt werden. Ab Visual Studio 17.3 Preview 2 können Sie native Anwendungen mit WinAppSDK auf Arm64-Geräten entwickeln.

Informationen zu den ersten Schritten bei der Entwicklung auf einem Arm64-Gerät finden Sie unter Windows auf Arm und Arm64 Visual Studio.

Benachrichtigungen

AppNotificationBuilder wurde als Alternative zur XML-Payload zum Erstellen und Definieren von App-Benachrichtigungen eingeführt.

Informationen zur Verwendung finden Sie in der Spezifikation zu AppNotificationBuilder auf GitHub.

Ein Beispiel zum Erstellen einer Windows-Desktopanwendung, die lokale App-Benachrichtigungen sendet und empfängt, finden Sie auch unter Schnellstart: App-Benachrichtigungen im Windows App SDK.

Wichtige Änderung

Damit Pushbenachrichtigungen verarbeitet werden, müssen Apps beim Senden eines Anforderungsaufrufs für den Kanal die Azure-Objekt-ID anstelle der Azure-App-ID verwenden. Weitere Informationen zum Suchen nach Ihrer Azure-Objekt-ID finden Sie unter Schnellstart: Pushbenachrichtigung im Windows App SDK.

Behobenes Problem

PushNotificationManager.IsSupported führt eine Überprüfung auf den Modus mit erhöhten Rechten durch. Wenn die App über erhöhte Rechte verfügt, wird false zurückgegeben.

Bekannte Einschränkungen (Benachrichtigungen)

• In AppNotificationScenario wird Urgent nur für den Windows-Build 19041 und höher unterstützt. Sie können AppNotificationBuilder.IsUrgentScenarioSupported verwenden, um zur Laufzeit zu überprüfen, ob das Feature verfügbar ist.
• In AppNotificationButton werden hint-toolTip und hint-buttonStyle werden nur für den Build 19041 und höher unterstützt. Sie können IsButtonStyleSupported und IsToolTipSupported verwenden, um zur Laufzeit zu überprüfen, ob das Feature verfügbar ist.
• Wenn MediaPlayerElement im XAML-Markup für eine nicht gepackte App verwendet wird, kann die Source-Eigenschaft nicht mit einem ms-appx- oder ms-resource-URI festgelegt werden. Alternativ dazu können Sie die Quelle mithilfe eines Datei-URI oder im Code festlegen.

Windowing

Eine vollständige Anpassung der Titelleiste ist jetzt unter Windows 10, Version 1809 und höher über die AppWindowTitleBar-Klasse verfügbar. Sie können AppWindowTitleBar.ExtendContentIntoTitleBar auf true festlegen, um Inhalte in den Titelleistenbereich zu erweitern, und Sie können SetDragRectangles festlegen, um Ziehbereiche (zusätzlich zu anderen Anpassungsoptionen) zu definieren.

Wenn Sie die Eigenschaft AppWindowTitleBar.IsCustomizationSupported verwendet haben, um zu überprüfen, ob Sie die AppWindowTitleBar-APIs aufrufen können, gibt sie in unterstützten Versionen von Windows 10 (1809 und höher) für Windows App SDK jetzt true zurück.

Bekannte Einschränkungen (Fensterfunktionen)

Grundlegende Titelleistenanpassungen werden unter Windows 10 nicht unterstützt. Dazu gehören BackgroundColor, InactiveBackgroundColor, ForegroundColor, InactiveForegroundColor und IconShowOptions. Wenn Sie diese Eigenschaften aufrufen, werden sie ohne Rückmeldung ignoriert. Alle anderen AppWindowTitleBar-APIs funktionieren unter Windows 10, Version 1809 und höher. Für die APIs für die Farben von Schaltflächen für Untertitel (u. a.) sowie für Height muss ExtendsContentIntoTitleBar auf true festgelegt werden, andernfalls werden sie ebenfalls ohne Rückmeldung ignoriert.

Zugriffssteuerung

Security.accesscontrol.h mit der Funktion GetSecurityDescriptorForAppContainerNames wurde eingeführt, um die gemeinsame Nutzung benannter Objekte für gepackte Prozesse und allgemeine Win32-APIs zu vereinfachen und zu optimieren. Diese Methode akzeptiert eine Liste mit Paketfamiliennamen (Package Family Names, PFNs) und Zugriffsmasken und gibt einen Sicherheitsdeskriptor zurück. Weitere Informationen finden Sie in der Spezifikation zu GetSecurityDescriptorForAppContainerNames auf GitHub.

Weitere Einschränkungen und bekannte Probleme

Wichtig

Wenn Sie aus einem Projekt auf WinAppSDK 1.2 verweisen, wird möglicherweise ein Fehler ähnlich dem folgenden angezeigt: Paketdowngrade erkannt: Microsoft.Windows.SDK.BuildTools von 10.0.22621.1 auf 10.0.22000.194. Dieser wird durch inkompatible Verweise auf das Paket aus dem App-Projekt und dem WinAppSDK-Paket verursacht. Um dies zu beheben, können Sie den Verweis im Projekt auf eine neuere und kompatible Version von Microsoft.Windows.SDK.BuildTools aktualisieren.

• Komponententests können mit einem REGDB_E_CLASSNOTREG-Fehler im Testausgabebereich in Visual Studio fehlschlagen. Als Problemumgehung können Sie Ihrer Projektdatei <WindowsAppContainer>true</WindowsAppContainer> hinzufügen.
• .NET PublishSingleFile wird nicht unterstützt.
• Die Standardwerte für die automatischen Initialisierer von Bootstrapper und Undocked RegFree WinRT sind (jetzt) nur für Projekte festgelegt, die eine ausführbare Datei erzeugen (OutputType: „Exe“ oder „WinExe“). Dies verhindert das standardmäßige Hinzufügen automatischer Initialisierer zu Klassenbibliothek-DLLs und anderen nicht ausführbaren Dateien.
  • Wenn Sie einen automatischen Initialisierer in einer nicht ausführbaren Datei benötigen (z. B. eine Test-DLL, die von einer generischen ausführbaren Datei geladen wird, die den Bootstrapper nicht initialisiert), können Sie einen automatischen Initialisierer in Ihrem Projekt explizit über <WindowsAppSdkBootstrapInitialize>true</WindowsAppSdkBootstrapInitialize> oder <WindowsAppSdkUndockedRegFreeWinRTInitialize>true</WindowsAppSdkUndockedRegFreeWinRTInitialize> aktivieren.
• Microsoft.WindowsAppRuntime.Release.Net.dll ist immer die Arm64-Binärdatei und funktioniert nicht für x86- und x64-Apps. Wenn die Bootstrap-API explizit aufgerufen wird, verwenden Sie nicht die Microsoft.WindowsAppRuntime.Release.Net.dll-Assembly. Als Problemumgehung können Sie Versionskonstanten in diese Quelldatei einschließen, die mit dem NuGet-Paket verteilt wird: „..\include\WindowsAppSDK-VersionInfo.cs“. Alternativ dazu können Sie den automatischen Initialisierer verwenden.

Version 1.1

Die neueste verfügbare Version der 1.1.x-Reihe des stabilen Kanals des Windows App SDK ist Version 1.1.5. 1.1.x unterstützt alle Features des stabilen Kanals (siehe Abschnitt Verfügbare Features im Releasekanal in Windows App SDK-Releasekanäle).

Version 1.1.5

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

Programmfehlerbehebung

• Ein Problem wurde behoben, bei dem der Acrylhintergrund nicht funktioniert, wenn Mica aktiviert ist. Weitere Informationen finden Sie im Issue #7200 auf GitHub.
• Ein Problem wurde behoben, das dazu führte, dass Apps, die das WindowsAppRuntime-Installationsprogramm benötigen (z. B. nicht gepackte Apps), auf Windows 10-ARM64-Computern nicht ausgeführt wurden. Weitere Informationen finden Sie im Issue #2564 auf GitHub.

Version 1.1.4

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

Programmfehlerbehebung

• Die Regression von 1.0.x wurde behoben, die dazu führte, dass ListView, TreeView und andere List-Steuerelemente beim Scrollen mit vielen Elementen abstürzten. Weitere Informationen finden Sie im Issue #7230 auf GitHub.
• Es wurde ein Problem mit DispatcherQueue behoben, das dazu führte, dass in die Warteschlange eingereihte Rückrufe nicht mehr aufgerufen wurden.
• Ein Problem wurde behoben, das beim mehrfachen Aufrufen von DeploymentManager.Initialize in derselben App-Sitzung einen App-Absturz verursachte.
• Ein Problem wurde behoben, das dazu führte, dass C#-Apps in Arm64 Visual Studio nicht kompiliert wurden. Weitere Informationen finden Sie im Issue #7140 auf GitHub.
• Es wurde ein zeitweiliger Absturz im XAML-Imagingcode aufgrund falscher Fehlerbehandlung behoben.
• Es wurde ein Speicherverlustproblem beim Anfügen eines Ereignishandlers in ItemsRepeater mit einem übergeordneten UserControl behoben. Weitere Informationen finden Sie im Issue #6123 auf GitHub.
• Ein Problem wurde behoben, das einen Buildfehler in Visual Studio 17.3 verursachte, wenn ein App-Projekt so konfiguriert war, dass beim Querladen (d. h. .appinstaller) automatische Updates des Pakets aktiviert wurden. Weitere Informationen finden Sie im Issue #2773.
• Ein Problem wurde behoben, durch das über den Store verteilte gepackte Apps, die Initialize aufrufen (z. B. für Push erforderlich), diesen Aufruf unnötigerweise durchführten, weil „DeploymentManager::GetStatus“ den Wert Package Install Needed zurückgab, wenn bereits Haupt- und Singletonpakete installiert waren. Dies führte zu einer Leistungsminderung beim App-Start.
• Ein Problem wurde behoben, das eine Ausnahme bei Einzelinstanzen-Apps verursachte, wenn das Bereinigungsereignis ignoriert werden sollte, wenn es nicht geöffnet werden konnte. Weitere Informationen finden Sie in diesem Pull Request auf GitHub.

Version 1.1.3

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

Programmfehlerbehebung

• Es wurden miteinander in Beziehung stehende Probleme behoben, bei denen XAML abstürzte, wenn die erste Seite Ihrer App ein ProgressBar-, ProgressRing-, PipsPager-, PersonPicture- oder Expander-Steuerelement enthielt. Weitere Informationen finden Sie im Issue #7164 auf GitHub.
• Ein Problem wurde behoben, das dazu führte, dass das x64-Installationsprogramm die Windows App SDK-Runtime nicht installierte. Weitere Informationen finden Sie im Issue #2713 auf GitHub.
• Ein Problem wurde behoben, das dazu führte, dass WindowsAppRuntime nicht installiert werden konnte, wenn eine höhere Version der Runtime installiert war. Weitere Informationen finden Sie in der Diskussion #2708 auf GitHub.

Version 1.1.2

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

Programmfehlerbehebung

• Ein Problem wurde behoben, bei dem XAML abstürzte, wenn ein Fenster geschlossen wurde, während ein Dialogfeld geöffnet war. Weitere Informationen finden Sie im Issue #1032 auf GitHub.
• Das Tag <auto-generated> wurde in C#-Dateien hinzugefügt, um StyleCop-Warnungen zu verhindern. Weitere Informationen finden Sie im Issue #4526 auf GitHub.
• Ein Problem wurde behoben, das beim Aufruf von MddBootstrapInitialize zu einem Zugriffsverletzungsfehler und einem Absturz führte, wenn das entsprechende Frameworkpaket nicht installiert war. Weitere Informationen finden Sie im Issue #2592 auf GitHub.
• Ein Problem wurde behoben, bei dem die C#-WinUI 3-Elementvorlagen in Visual Studio fehlten. Weitere Informationen finden Sie im Issue #7148 auf GitHub.
• Ein Problem wurde behoben, bei dem beim Ausführen des WindowsAppRuntime-Installationsprogramms als Systembenutzer ein Fehler auftrat. Weitere Informationen finden Sie im Issue #2546 auf GitHub.

Version 1.1.1

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

Programmfehlerbehebung

• Ein Problem wurde behoben, das dazu führte, dass Apps während eines Drag & Drop-Vorgangs manchmal abstürzten. Weitere Informationen finden Sie im Issue #7002 auf GitHub.
• Ein Problem wurde behoben, das dazu führte, dass die Titelleiste nicht mehr angezeigt wurde, wenn AppWindowPresenterKind von FullScreen zu Default wechselte.
• Ein Problem wurde behoben, bei dem Bootstrapper-APIs wie ApiInformation.IsPropertyPresent und ApiInformation.IsMethodPresent nicht behandelte Ausnahmen in Apps verursachten, die nicht gepackt waren. Weitere Informationen finden Sie im Issue #2382 auf GitHub.
• Ein Problem wurde behoben, das zum Einfrieren einer App beim Maximieren der Anwendung mit Stifteingabe führte.

Version 1.1

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

Hinweis

Für die C#-Entwicklung ist eine der folgenden .NET SDK-Versionen (oder höher) erforderlich: 6.0.202, 6.0.104, 5.0.407, 5.0.213. Zum Aktualisieren Ihrer .NET SDK-Version besuchen Sie die Download-Website für .NET, oder aktualisieren Sie Visual Studio auf die neueste Version. Wenn Sie Ihr NuGet-Paket ohne die erforderliche .NET SDK-Version aktualisieren, wird ein Fehler wie dieser angezeigt: Diese Version von WindowsAppSDK erfordert WinRT.Runtime.dll Version 1.6 oder höher.

App-Lebenszyklus und -Neustart

Apps können jetzt einen expliziten Neustart mit bestimmten Argumenten und einem bestimmten Zustand initiieren, aufbauend auf der vorhandenen RegisterApplicationRestart-API zum Registrieren beim Betriebssystem, um in Szenarien mit Updates, Abstürzen oder Reboots neu starten zu können.

Neue Features:

• Jede gepackte oder nicht gepackte Desktop-App kann sich mithilfe der AppInstance.Restart()-API per Befehl selbst beenden und neu starten und auf eine zufallsbasierte Befehlszeilenzeichenfolge für die neu gestartete Instanz zugreifen.
  • Dies ist eine überarbeitete und synchrone Version der UWP-RequestRestartAsync()-API, die einen Neustart mit Argumenten ermöglicht und einen AppRestartFailureReason zurückgibt, wenn der Neustart nicht erfolgreich ist.
  • Informationen zur Verwendung sowie weitere Referenzen finden Sie in der Dokumentation zu Neustart API auf GitHub.

WinUI 3

WinUI 3 ist das native UX-Framework (User Experience) für Windows App SDK. Dieses Release enthält neue Features aus WinAppSDK 1.0 sowie mehrere Stabilitätsverbesserungen aus den Vorschauversionen 1.0 und 1.1.

Neue Features:

• Mica und Background Acrylic sind jetzt für WinUI 3-Anwendungen verfügbar.
  • Weitere Informationen zu diesen Materialien finden Sie unter Materialien in Windows 11. Sehen Sie sich unseren Beispielcode zum Anwenden von Mica in C++-Anwendungen unter Verwenden eines SystemBackdropController mit WinUI 3-XAML an. den Code zum Anwenden von Mica in C#-Anwendungen finden Sie auf GitHub im WinUI 3-Katalog an.
• Wir haben die Erstellung mehrerer Fenster im selben Thread in WinUI 3-Anwendungen, die erstmals in Version 1.0.1 eingeführt wurde, jetzt stabilisiert und aktiviert. Weitere Informationen finden Sie im Issue #5918.

Korrigierte Fehler:

• Es wurde ein Problem bei der Verwendung von Mica behoben, bei dem die App abstürzte, wenn ein Fenster gleichmäßig auf zwei Bildschirme aufgeteilt war. Weitere Informationen finden Sie im Issue #7079 auf GitHub.
• Durch Upgrade des WebView2 SDK von 1020.46 auf 1185.39 wurde ein Problem behoben, das dazu führte, dass C#-Apps mit WebView2 beim Start abstürzten, wenn die C/C++ Runtime (CRT) nicht installiert war.
• Ein Problem wurde behoben, das dazu führte, dass in einigen abgerundeten Ecken ein Farbverlauf angezeigt wurde, obwohl es sich um eine Volltonfarbe handeln sollte. Weitere Informationen finden Sie in Issue 6076 und Issue 6194 auf GitHub.
• Ein Problem wurde behoben, bei dem aktualisierte Stile in generic.xaml fehlten.
• 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, bei dem Benutzer*innen ein Element nicht löschen konnten, wenn Drag & Drop aktiviert ist. Weitere Informationen finden Sie im Issue #7008 auf GitHub.

Bekannte Einschränkungen:

• Bei Verwendung einer benutzerdefinierten Titelleiste ändern die Steuerelemente für Untertitel die Farbe nicht, wenn das Design geändert wird.
• XAML stürzt ab, wenn Benutzer*innen ein Fenster schließen, während ein Dialogfeld geöffnet ist.

Bereitstellung

Neue Features:

• Gepackte Apps können jetzt die Bereitstellung der Windows App SDK-Laufzeitpakete mithilfe der DeploymentManager.Initialize(DeploymentInitializeOptions)-API oder mithilfe der Option „--force“ mit dem Windows App Runtime-Installer erzwingen.
• Es gibt zusätzliche funktionsbezogene Erweiterungskategorien, UnlockedDEHs, die für gepackte Apps verfügbar sind. Weitere Informationen finden Sie in den Versionshinweisen zu 1.1 Preview 3. Hierfür muss das Windows App SDK-Frameworkpaket installiert sein. Informationen zum Installieren der Runtime finden Sie bei den Downloads für das Windows App SDK.
• Die eigenständige Bereitstellung wird unterstützt. Informationen zu den Unterschieden zwischen frameworkabhängiger und eigenständiger Bereitstellung sowie zu den ersten Schritten finden Sie in der Übersicht über die Windows App SDK-Bereitstellung .
• Die Bootstrapper-API, die für Apps erforderlich ist, die nicht mit MSIX bereitgestellt werden, enthält neue Optionen für verbesserte Benutzerfreundlichkeit und Problembehandlung. Sehen Sie sich unsere Dokumentation für C#-Apps unter Bootstrapper-C#-APIs und für C++-Apps unter mddbootstrap.h-Header an. Weitere Informationen finden Sie unter Verwenden der Windows App SDK-Runtime für gepackte Apps mit externem Speicherort oder nicht gepackte Apps.

Bekannte Einschränkungen:

• Damit der Windows App Runtime-Installer (WindowsAppRuntimeInstall.exe) ausgeführt werden kann, muss Querladen aktiviert sein. Weitere Informationen finden Sie im Issue #2469 auf GitHub.
• Beim Erstellen eines MSIX-Pakets über die Visual Studio-Projektmenüs kann Visual Studio in einigen Szenarien abstürzen. Dieses Problem wird in Visual Studio, Version 17.3 Preview 2 behoben. Für Version 17.2 wird ein Wartungsupdate bereitgestellt. Wenn dieses Problem auftritt, können Sie es umgehen, indem Sie ein MSIX-Paket über die Befehlszeile generieren, zu einem nicht gepackten Projekt wechseln oder zum Windows App SDK 1.0 zurückkehren.
• Eigenständige Anwendungen, die mit MSIX gepackt sind, werden in 1809 nicht unterstützt, was zum Absturz der App beim Start führt.

Elevation

Apps können jetzt mit erhöhten Rechten ausgeführt werden.

Bekannte Einschränkungen:

• Die Unterstützung für erhöhte Rechte erfordert die folgenden Wartungsupdates für diese Betriebssysteme:
  • Win11: 10. Mai 2022 – KB5013943 (Betriebssystembuild 22000.675)
  • Win10: 10. Mai 2022 – KB5013942 (Betriebssystembuilds 19042.1706, 19043.1706 und 19044.1706)
• App- und Pushbenachrichtigungen für eine nicht gepackte App mit erhöhten Rechten werden nicht unterstützt.
• WinUI 3-Apps mit erhöhten Rechten stürzen ab, wenn während einer Drag & Drop-Interaktion ein Element gezogen wird.

Umgebungsvariablen-Manager

Der Umgebungsvariablen-Manager ist eine neue API, die in Windows App SDK 1.1 eingeführt wurde. Mit dem Umgebungsvariablen-Manager können Entwickler*innen über eine einzige API-Oberfläche auf Umgebungsvariablen auf Prozess-, Benutzer- und Computerebene zugreifen und diese ändern.

Wenn der Umgebungsvariablen-Manager in einer gepackten Anwendung verwendet wird, werden alle Umgebungsvariablenvorgänge aufgezeichnet. Wenn das Paket entfernt wird, werden alle Umgebungsvariablenvorgänge rückgängig gemacht.

Neue Features:

• Sie können Umgebungsvariablen auf Prozess-, Benutzer- und Computerebene abrufen und festlegen.
• Automatische Umgebungsvariablen werden rückgängig gemacht, wenn ein Paket entfernt wird, das den Umgebungsvariablen-Manager verwendet.
• Enthält bestimmte APIs für PATH und PATHEXT.

Bekannte Einschränkungen:

• Ist nur unter Windows 11 verfügbar.

MRT Core

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

Behobene Probleme:

• In .NET SDK 6.0.300 wurde ein Problem behoben, das dazu führte, dass Ressourcen nicht standardmäßig indiziert wurden, wenn eine Ressourcendatei über die VS-Benutzeroberfläche hinzugefügt wurde. Wenn Sie eine ältere .NET SDK-Version verwenden, nutzen Sie weiterhin die Problemumgehung, die in den Versionshinweisen von 1.0 dokumentiert ist. Weitere Informationen finden Sie im Issue #1786 auf GitHub.
• In Visual Studio 2022 17.2 wurde ein Problem behoben, das dazu führte, dass der Ressourcen-URI in nicht gepackten C++-WinUI 3-Apps nicht ordnungsgemäß erstellt wurde. Wenn Sie eine ältere Visual Studio-Version verwenden, aktualisieren Sie Visual Studio auf Version 17.2, um diese Korrektur zu erhalten.

Bekannte 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 auf GitHub.

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

Benachrichtigungen

Entwickler*innen von gepackten Apps (einschließlich gepackten Apps mit externem Speicherort) und nicht gepackten Apps können jetzt Windows-Benachrichtigungen senden.

Neue Features:

• Unterstützung für App-Benachrichtigungen für gepackte und nicht gepackte Apps.
  • Entwickler*innen können App-Benachrichtigungen – auch als Popupbenachrichtigungen bezeichnet – lokal oder über ihren eigenen Clouddienst senden. Siehe Übersicht über App-Benachrichtigungen.
• Unterstützung für Pushbenachrichtigungen für gepackte und nicht gepackte Apps.
  • Entwickler*innen können unformatierte Benachrichtigungen und App-Benachrichtigungen über ihren eigenen Clouddienst senden. Siehe Übersicht über Pushbenachrichtigungen.

Bekannte Einschränkungen:

• Das Senden von Benachrichtigungen von einer App mit erhöhten Rechten wird nicht unterstützt. PushNotificationManager::IsSupported() führt keine Überprüfung auf den Modus mit erhöhten Rechten durch.

Windowing

Für einen einfacheren Programmierzugriff auf Funktionen, die in USER32.dll implementiert sind (siehe Fenster und Meldungen), zeigt dieses Release mehr von dieser Funktionalität in AppWindow selbst.

Neue Features:

• Apps mit vorhandenen Fenstern haben durch Aufrufen von AppWindow.ShowOnceWithRequestedStartupState – dem Äquivalent zu ShowWindow(SW_SHOWDEFAULT) – mehr Kontrolle darüber, wie ein Fenster angezeigt wird.
• Apps können ein Fenster anzeigen, minimieren oder wiederherstellen. Sie können auch angeben, ob das Fenster zum Zeitpunkt des Aufrufs aktiviert werden soll oder nicht.
• Apps können jetzt bestimmte Dimensionen für die Clientbereichsgröße ihres Fensters in Win32-Koordinaten bestimmen, ohne die Größe des Nicht-Clientbereichs berechnen zu müssen, um eine bestimmte Clientbereichsgröße zu erhalten.
• Zur Unterstützung der Verarbeitung der Z-Reihenfolge von Fenstern basierend auf der Funktionalität des SetWindowPos-Parameters „hWndInsertAfter“ sind zusätzliche WinRT-APIs verfügbar.
• Apps, die benutzerdefinierte Titelleisten mit AppWindowTitleBar.ExtendsContentIntoTitleBar zeichnen, können eine PreferredTitleBarHeight-Option festlegen. Sie haben jetzt die Auswahl zwischen einer Titelleiste mit Standardhöhe oder einer hohen Titelleiste, die mehr Platz für interaktive Inhalte bietet. Informationen zur Verwendung einer hohen Titelleiste finden Sie unter Titelleiste in den Fluent Design-Richtlinien.

Behobene Probleme:

• Wenn der Vollbild-Presenter zum ersten Mal aufgerufen wird, passt das Fenster jetzt ordnungsgemäß auf den gesamten Bildschirm. Weitere Informationen finden Sie im Issue #1853 auf GitHub.
• Für mit AppWindow::GetFromWindowId erstellte Fenster ist OverlappedPresenter der Standard-Presenter, es gibt aber keine Einschränkungen in Bezug auf Änderungen an Fensterstilen, die von anderen APIs stammen. Für mit AppWindow::Create erstellte Fenster gelten von Anfang an die standardmäßigen Presenter-Richtlinien. Weitere Informationen finden Sie im Issue #2049 auf GitHub.
• Die Verwendung der OverlappedPresenter.SetBorderAndTitlebar-API zum Ausblenden von Schaltflächen und Rahmen für Untertitel führte bei Maximierung des Fensters zu einem oberen Rand von 1 Pixel. Dieses Problem wurde gelöst. Weitere Informationen finden Sie im Issue #1693 auf GitHub.

Bekannte Einschränkungen:

• Wenn Sie die AppWindowTitlebar-API zum Anpassen der Farben der Standardtitelleiste verwenden, sind Symbol und Text im Vergleich zur Standardtitelleiste falsch ausgerichtet. Weitere Informationen finden Sie im GitHub-Issue #2459.

• Beim Lösen des GitHub-Issues #2049 (siehe oben) entstand der folgende Fehler: Wenn Sie einen AppWindowPresenter auf ein AppWindow anwenden, das Sie aus GetFromWindowId abgerufen haben, dann durch Aufrufen von USER32-APIs einen durch diesen Presenter nachverfolgten Fensterstil ändern und dann versuchen, durch erneutes Anwenden des Standard-Presenters zum vorherigen Zustand des Fensters zurückzukehren, ist das Ergebnis ein Fenster ohne Titelleiste. Wenn Sie in Ihrer App einen Presenter verwenden und Fensterstile mithilfe von USER32-Aufrufen zu einem Zeitpunkt ändern, zu dem ein nicht standardmäßiger Presenter gültig ist, müssen Sie möglicherweise eine Problemumgehung hinzufügen, um das korrekte Fensterverhalten sicherzustellen, bis dieser Fehler behoben ist. Sie können den folgenden Codeschnipsel als Vorlage für diese Problemumgehung verwenden:

  AppWindow m_appWindow;
  OverlappedPresenter m_defaultPresenter;
  
  private void EnterFullScreen_Click(object sender, RoutedEventArgs e)
  {
      // Capture the default presenter.
      m_defaultPresenter = m_appWindow.Presenter as OverlappedPresenter;
  
      // Opt in the default overlapped presenter so it can control various aspects of the AppWindow.
      m_defaultPresenter.IsAlwaysOnTop = m_defaultPresenter.IsAlwaysOnTop;
      m_defaultPresenter.IsResizable = m_defaultPresenter.IsResizable;
      m_defaultPresenter.IsMinimizable = m_defaultPresenter.IsMinimizable;
      m_defaultPresenter.IsMaximizable = m_defaultPresenter.IsMaximizable;
      m_defaultPresenter.SetBorderAndTitleBar(m_defaultPresenter.HasBorder, m_defaultPresenter.HasTitleBar);
  
      m_appWindow.SetPresenter(AppWindowPresenterKind.FullScreen);
  }
  
  private void ExitFullScreen_Click(object sender, RoutedEventArgs e)
  {
      m_appWindow.SetPresenter(AppWindowPresenterKind.Default);
  }
  

C#/WinRT

C#-Komponenten für die Windows-Runtime werden jetzt unterstützt, einschließlich benutzerdefinierter WinUI-Steuerelemente. Dadurch können in C# geschriebene Runtimekomponenten an jede WinRT-kompatible Sprache (z. B. C++/WinRT) verteilt werden. Informationen für den Einstieg finden Sie unter Exemplarische Vorgehensweise: Erstellen einer C#-Komponente mit WinUI 3-Steuerelementen und Verwenden dieser aus einer C++/WinRT-App, die das Windows App SDK nutzt sowie im Beispiel auf GitHub.

Weitere Einschränkungen und bekannte Probleme

• Apps, die auf ein Paket verweisen, das WebView2 erfordert (z.B. Microsoft.Identity.Client), können nicht kompiliert werden. Dies wird durch miteinander in Konflikt stehende Binärdateien zur Buildzeit verursacht. Weitere Informationen finden Sie im Issue 2492 auf GitHub.
• Bei Verwendung von dotnet build mit einem WinAppSDK C#-Klassenbibliothek-Projekt kann der Build-Fehler „Microsoft.Build.Packaging.Pri.Tasks.ExpandPriContent task could not be loaded“ auftreten. Um dieses Problem zu beheben, legen Sie <EnableMsixTooling>true</EnableMsixTooling> in Ihrer Projektdatei fest.
• Die WinAppSDK-Standardvorlagen enthalten diesen Hinweis: MaxVersionTested="10.0.19041.0". Es sollte sich aber um 10.0.22000.0 handeln. Aktualisieren Sie MaxVersionTested in Ihrer Projektdatei auf 10.0.22000.0, um die vollständige Unterstützung für einige Features zu erhalten, insbesondere UnlockedDEHs.

Version 1.0

Die neueste verfügbare Version der 1.0.x-Reihe des stabilen Kanals des Windows App SDK ist Version 1.0.4. 1.0.x unterstützt alle Features des stabilen Kanals (siehe Abschnitt Verfügbare Features im Releasekanal in Windows App SDK-Releasekanäle).

Version 1.0.4

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

Programmfehlerbehebung

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

Programmfehlerbehebung

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

Programmfehlerbehebung

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

Programmfehlerbehebung

• 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 und 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 Issue 6333 und 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. Vorlage.
• 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.
• 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 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 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 und 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):

  • Einige APIs erfordern eine Paketidentität und werden in nicht gepackten Apps nicht unterstützt, z. B.:
    • ApplicationData
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • ApiInformation (unter Windows 10 nicht unterstützt)
    • Package.Current
    • Jede API im Namespace Windows.ApplicationModel.Resources
    • Jede API im Namespace Microsoft.Windows.ApplicationModel.Resources

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

• Windows-UI 3-Bibliothek (WinUI)
• Erstellen Ihres ersten WinUI 3-Projekts

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 Funktionen

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

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 Funktionen

• 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

  • Nicht gepackte Apps: Vollständig verwendbar.
  • Gepackte Apps: Verwendbar, aber diese Apps können auch die GetActivatedEventArgs der Plattform verwenden. Beachten Sie, dass die Plattform Windows.ApplicationModel.AppInstance definiert, während das Windows App SDK Microsoft.Windows.AppLifecycle.AppInstance definiert. Und während UWP-Apps die ActivatedEventArgs-Klassen wie FileActivatedEventArgs und LaunchActivatedEventArgs verwenden können, müssen Apps, die das AppLifecycle-Feature des Windows App SDK nutzen, die Schnittstellen verwenden, nicht die Klassen (z. B. IFileActivatedEventArgs, ILaunchActivatedEventArgs usw.).
  • WinUI-Apps: App.OnLaunched von WinUI empfängt eine Microsoft.UI.Xaml.LaunchActivatedEventArgs-Klasse, während die Plattform-GetActivatedEventArgs eine Windows.ApplicationModel.IActivatedEventArgs-Schnittstelle zurückgibt. WindowsAppSDK-GetActivatedEventArgs gibt ein Microsoft.Windows.AppLifecycle.AppActivationArguments-Objekt zurück, das eine LaunchActivatedEventArgs-Plattformklasse darstellen kann.
  • Weitere Informationen finden Sie unter Umfassende Aktivierung.

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

  • Nicht gepackte Apps: Vollständig verwendbar.
  • Gepackte Apps: Nicht verwendbar. Verwenden Sie stattdessen das MSIX-Manifest der App.
  • Weitere Informationen finden Sie unter 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.

• Benachrichtigungen zu Energieversorgung/Zustand

  • Nicht gepackte Apps: Vollständig verwendbar.
  • Gepackte Apps: Vollständig verwendbar.
  • Weitere Informationen finden Sie unter Energieverwaltung.

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.

Features: 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

• Sie können die Windows App SDK über die WindowsPackageType project-Eigenschaft automatisch initialisieren, um die Windows App SDK-Runtime zu laden und die Windows App SDK-APIs aufzurufen. Anweisungen finden Sie unter Erstellen Ihres ersten WinUI 3-Projekts.
• Nicht gepackte Apps können das Windows App SDK bereitstellen, indem sie in das eigenständige Windows App SDK-Installationsprogramm .exe in Ihr vorhandenes MSI-Paket oder Setupprogramm integrieren. Weitere Informationen finden Sie im Windows App SDK-Bereitstellungsleitfaden für frameworkabhängige gepackte Apps mit externem Speicherort oder nicht gepackte Apps.
• Nicht gepackte .NET-Apps können auch einen .NET-Wrapper für die Bootstrapper-API verwenden, um zur Laufzeit dynamisch eine Abhängigkeit vom Windows App SDK-Frameworkpaket zu akzeptieren. Weitere Informationen zum .NET-Wrapper finden Sie in der .NET-Wrapper-Bibliothek.
• Gepackte Apps können die Bereitstellungs-API verwenden, um zu verifizieren und sicherzustellen, dass alle erforderlichen Pakete auf dem Computer installiert sind. 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.

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

Version 0.8

Die neueste verfügbare Version der 0.8.x-Reihe des stabilen Kanals des Windows App SDK ist Version 0.8.12.

Hinweis

Das Windows-App SDK war zuvor unter dem Codenamen Project Reunion bekannt. Einige SDK-Ressourcen in Version 0.8 und früher verwenden weiterhin den Codenamen. In einigen Bereichen der Dokumentation wird weiterhin Project Reunion verwendet, wenn auf eine vorhandene Ressource oder ein angegebenes früheres Release verwiesen wird.

Version 0.8.12

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

Hinweis

Für die C#-Entwicklung ist eine der folgenden .NET SDK-Versionen erforderlich: 5.0.213, 5.0.407, 6.0.104, 6.0.202 (oder höher). Zum Aktualisieren Ihrer .NET SDK-Version besuchen Sie die Download-Website für .NET, oder aktualisieren Sie Visual Studio auf die neueste Version. Wenn Sie Ihr NuGet-Paket ohne die erforderliche .NET SDK-Version aktualisieren, wird ein Fehler wie dieser angezeigt: Diese Version von WindowsAppSDK erfordert WinRT.Runtime.dll Version 1.6 oder höher.

Fehlerkorrekturen:

• Ein Problem wurde behoben, bei dem Apps mit SwapChainPanel oder WebView2 aufgrund einer Zugriffsverletzung unvorhersehbar abstürzten.

Version 0.8.11

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

Hinweis

Für die C#-Entwicklung ist eine der folgenden .NET SDK-Versionen erforderlich: 5.0.213, 5.0.407, 6.0.104, 6.0.202 (oder höher). Zum Aktualisieren Ihrer .NET SDK-Version besuchen Sie die Download-Website für .NET, oder aktualisieren Sie Visual Studio auf die neueste Version. Wenn Sie Ihr NuGet-Paket ohne die erforderliche .NET SDK-Version aktualisieren, wird ein Fehler wie dieser angezeigt: Diese Version von WindowsAppSDK erfordert WinRT.Runtime.dll Version 1.6 oder höher.

Fehlerkorrekturen:

• Die Regression wurde behoben, die dazu führte, dass beim Auswählen von Text mit der Maus das Ereignis „Fokusverlust“ ausgelöst wurde.

Version 0.8.10

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

Hinweis

Für die C#-Entwicklung ist eine der folgenden .NET SDK-Versionen erforderlich: 5.0.213, 5.0.407, 6.0.104, 6.0.202 (oder höher). Zum Aktualisieren Ihrer .NET SDK-Version besuchen Sie die Download-Website für .NET, oder aktualisieren Sie Visual Studio auf die neueste Version. Wenn Sie Ihr NuGet-Paket ohne die erforderliche .NET SDK-Version aktualisieren, wird ein Fehler wie dieser angezeigt: Diese Version von WindowsAppSDK erfordert WinRT.Runtime.dll Version 1.6 oder höher.

Fehlerkorrekturen:

• Es wurden Probleme behoben, die dazu führten, dass Apps während eines Drag & Drop-Vorgangs manchmal abstürzten.

Hinweis

Windows App SDK 0.8.9 wurde nicht veröffentlicht. Die direkt nach 0.8.8 veröffentlichte Version ist 0.8.10.

Version 0.8.8

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

Hinweis

Für die C#-Entwicklung ist eine der folgenden .NET SDK-Versionen (oder höher) erforderlich: 6.0.202, 6.0.104, 5.0.407, 5.0.213. Zum Aktualisieren Ihrer .NET SDK-Version besuchen Sie die Download-Website für .NET, oder aktualisieren Sie Visual Studio auf die neueste Version. Wenn Sie Ihr NuGet-Paket ohne die erforderliche .NET SDK-Version aktualisieren, wird ein Fehler wie dieser angezeigt: Diese Version von WindowsAppSDK erfordert WinRT.Runtime.dll Version 1.6 oder höher.

Fehlerkorrekturen:

• Probleme mit der Toucheingabe in TextBox bei Interaktionen mit der Bildschirmtastatur und allgemeinen Interaktionen wurden behoben. Diese Probleme betrafen auch Tastenkombinationen. Weitere Informationen finden Sie im Issue #6291 auf GitHub.
• Ein Problem wurde behoben, bei dem ein App-Fenster manchmal als inaktiv angezeigt wurde, obwohl es aktiv war.
• Es wurde ein Leistungsproblem behoben, das durch die Ausführung von UIA (Benutzeroberflächenautomatisierung) in externen Prozessen verursacht wurde.
• Ein Problem mit der App-Stabilität bei Stifteingaben wurde behoben.
• Ein Problem wurde behoben, bei dem das Rendern von PNG-Symbolen in einem Menü aufgrund von UIA dramatisch verzögert wurde.

Version 0.8.7

Dies ist ein Wartungsrelease des Windows App SDK, das verschiedene Leistungsupdates für C#-/.NET-Anwendungen enthält. Zum Aktualisieren auf diese Version müssen Sie auf die neueste Windows SDK-Paketversion verweisen. Fügen Sie dazu die Eigenschaft <WindowsSdkPackageVersion>10.0.<sdk_version>.24</WindowsSdkPackageVersion> der .csproj-Datei mit der SDK-Version hinzu, die Ihre App über die Eigenschaft TargetFramework ansteuern soll. Beispiel:

<Project Sdk="Microsoft.NET.Sdk">
   <PropertyGroup>
       <OutputType>WinExe</OutputType>
       <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework>
       <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
       <WindowsSdkPackageVersion>10.0.19041.24</WindowsSdkPackageVersion>
   <PropertyGroup>
   ...

Diese Version der Windows SDK-Projektion wird in einem zukünftigen .NET 6-Wartungsrelease verfügbar sein. Sobald das .NET SDK-Update verfügbar ist, sollten Sie die <WindowsSdkPackageVersion>-Eigenschaft aus Ihrer Projektdatei entfernen.

Wenn Sie diese Eigenschaft nicht festlegen, wird ein Fehler wie dieser angezeigt: "Error: This version of Project Reunion requires WinRT.Runtime.dll version 1.6 or greater."

Version 0.8.6

Dies ist ein Wartungsrelease des Windows App SDK, das verschiedene Leistungsverbesserungen für C#-/.NET-Anwendungen für das Release 0.8.0 enthält.

Zum Aktualisieren auf diese Version des Windows App SDK müssen Sie das neueste .NET SDK-Update vom Dezember installiert haben (siehe Download-Website für .NET und .NET 5 will reach End of Support on May 10, 2022). Wenn die erforderliche Mindestversion des .NET SDK nicht installiert ist, wird ein Fehler wie "Error: This version of Project Reunion requires WinRT.Runtime.dll version 1.4 or greater." angezeigt

Programmfehlerbehebung

Eine ausführliche Liste der Leistungsverbesserungen finden Sie in den Release Notes zu C#/WinRT 1.4.1.

Version 0.8.5

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

Programmfehlerbehebung

• Ein Problem wurde behoben, das zum Absturz von WinUI-Apps mit Zeigereingaben führte.
• Ein Problem wurde behoben, das dazu führte, dass die Titelleistenschaltflächen (Minimieren, Maximieren, Schließen) unter Windows 11 keine abgerundeten Ecken aufwiesen.
• Ein Problem wurde behoben, das unter Windows 11 dazu führte, dass beim Zeigen mit der Maus auf die Schaltfläche „Maximieren/Wiederherstellen“ die Optionen für Layoutänderungen nicht angezeigt wurden.
• Ein Problem wurde behoben, das beim Erstellen eines PointCollection-Objekts eine Absturzausnahme verursachte. Weitere Informationen finden Sie im Issue 971 auf GitHub.

Die Einschränkungen und bekannten Probleme für Version 0.8 gelten auch für Version 0.8.5, sofern im folgenden Abschnitt nichts anderes angegeben ist.

Version 0.8.4

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

Programmfehlerbehebung

• Korrekturen für benutzerdefinierte Titelleisten, sodass ContentDialog sie nicht verdeckt und die Schaltflächen der Titelleiste abgerundet angezeigt werden.
• Korrektur für einen Absturz bei der Bildverarbeitung, wenn die Anzeigeskalierung geändert wird.
• Korrekturen für Fehler beim Freistellen, bei denen die Benutzeroberfläche nicht mehr angezeigt oder falsch freigestellt wurde.

Die Einschränkungen und bekannten Probleme für Version 0.8 gelten auch für Version 0.8.4, sofern im folgenden Abschnitt nichts anderes angegeben ist.

Version 0.8.3

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

Programmfehlerbehebung

Der Tastaturfokus ging verloren, wenn ein Fenster minimiert und dann wiederhergestellt wurde. Es war ein Mausklick erforderlich, um den Fokus wiederherzustellen.

Die Einschränkungen und bekannten Probleme für Version 0.8 gelten auch für Version 0.8.3, sofern im folgenden Abschnitt nichts anderes angegeben ist.

Version 0.8.2

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

Programmfehlerbehebung

• Windows App SDK und WinUI 3 werden jetzt in Visual Studio 2022 Preview 2 und höher unterstützt.
• Bei .NET-Apps erhalten Sie möglicherweise den folgenden Fehler, wenn Sie ein Array aus Enumerationen übergeben: Object contains non-primitive or non-blittable data.
• Schreiben unter Verwendung des Schreibbereichs in einem Textfeld führt zu einem Absturz.
• Symbole/Bilder werden immer mit ihrem Skalierungswert von 100 % geladen, statt basierend auf dem Monitorskalierungswert.
• Die Garbage Collection von EventSource<T> führt zu einem nachfolgenden Fehler beim Abbestellen von Handlern (weitere Details finden Sie in diesem GitHub-Issue).
• Sicherheitskorrektur: Details finden Sie unter CVE-2021-34533.
• SwapChainPanel.CompositionScaleChanged gibt nach dem Ändern der Anzeigeskalierung manchmal falsche CompositionScale-Werte zurück.

Die Einschränkungen und bekannten Probleme für Version 0.8 gelten auch für Version 0.8.2, sofern im folgenden Abschnitt nichts anderes angegeben ist.

Version 0.8.1

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

Programmfehlerbehebung

• Das Windows App SDK kann nicht mit dem neuesten Windows Insider-Build ausgeführt werden.
• Das Eingeben eines Werts, der nicht in der Dropdownliste angezeigt wird, führt zu einem Absturz in EditableComboBox.
• WebView2 erlaubt kein Verlassen mit der Tabulatortaste, sobald der Fokus empfangen wurde.
• Der Windows.Foundation.Metadata.DefaultOverload-Namespace im von WinUI generierten Code muss vollständig qualifiziert werden, um Mehrdeutigkeit bei Namespaces zu vermeiden.
  • Diese Korrektur behebt Fehler #5108.
• Sicherheitskorrektur: Details finden Sie unter CVE-2021-34489.

Die Einschränkungen und bekannten Probleme für Version 0.8 gelten auch für Version 0.8.1, sofern im folgenden Abschnitt nichts anderes angegeben ist.

Version 0.8.0 Stable

Neue Features und Updates

Dieses Release unterstützt alle Features des stabilen Kanals.

WinUI 3

Dieses Release enthält viele Fehlerbehebungen und eine verbesserte Stabilisierung für WinUI 3. Dies sind alle neuen Änderungen in WinUI 3 seit der Veröffentlichung von WinUI 3 – Project Reunion 0.5:

• Das Pivot-Steuerelement wurde wieder hinzugefügt und kann jetzt in jeder WinUI 3-App verwendet werden.

• Alle Fehlerbehebungen aus Project Reunion v0.5.5, v0.5.6 und v0.5.7 sind in diesem Release enthalten.

• Neue Fehlerbehebungen, einschließlich:

  • Beim Klicken mit der rechten Maustaste in „TextBox“ stürzt die Anwendung ab.
  • „NavigationView“ verursacht Absturz in UWP, Reunion 0.5 Preview.
  • ProgressBar zeigt den Unterschied zwischen „Angehalten“ und „Fehler“ nicht an
  • Kopieren/Einfügen/Ändern des Textstils führt zu einem Absturz in RichEditBox.
  • Schaltflächen für Fenstertitel werden falsch platziert, wenn SetTitleBar nicht festgelegt oder NULL ist.

  Eine vollständige Liste der in diesem Release behobenen Fehler finden Sie in unserem GitHub-Repository.

• Die ColorHelper.ToDisplayName-API ist nicht mehr verfügbar.

• Die folgenden Typen wurden entfernt:

  • Microsoft.Graphics.IGeometrySource2D
  • Microsoft.Graphics.IGeometrySource2DInterop

  Verwenden Sie stattdessen Windows.Graphics.IGeometrySource2D und Windows.Graphics.IGeometrySource2DInterop.

• Alle Typen im Microsoft.System-Namespace wurden in den Microsoft.UI.Dispatching-Namespace verschoben, einschließlich der DispatcherQueue-Klasse.

• Die AcrylicBrush.BackgroundSource-Eigenschaft wurde entfernt, da HostBackdrop als BackgroundSource in WinUI 3 nicht unterstützt wird.

Weitere Informationen zu WinUI finden Sie unter Windows-UI 3-Bibliothek (WinUI).

Um die WinUI 3-Steuerelemente und -Features in Aktion zu sehen, können Sie die WinUI 3-Katalog-App von GitHub klonen und kompilieren oder aus dem Microsoft Store herunterladen.

In den folgenden Artikeln finden Sie Informationen zu den ersten Schritten bei der Entwicklung mit WinUI:

• WinUI 3-Vorlagen in Visual Studio
• Erstellen Ihres ersten WinUI 3-Projekts
• Erstellen einer C# .NET App mit WinUI 3- und Win32-Interop
• WinUI 3-API-Referenz

DWriteCore

Dieses Release von DWriteCore enthält die folgenden neuen und aktualisierten Features. DWriteCore wird in der Übersicht über DWriteCore vorgestellt und beschrieben.

• DWriteCore bietet jetzt Unterstützung für Unterstreichungen – siehe IDWriteTextLayout::GetUnderline und IDWriteTextLayout::SetUnderline.
• Unterstützung für Durchstreichungen – siehe IDWriteTextLayout::GetStrikethrough und IDWriteTextLayout::SetStrikethrough.
• Unterstützung für vertikalen Text über IDWriteTextLayout – siehe Vertikaler Text.
• Alle Methoden der Schnittstellen IDWriteTextAnalyzer und IDWriteTextAnalyzer1 sind implementiert.
• Die freie Funktion DWriteCoreCreateFactory erstellt ein Factoryobjekt, das für die nachfolgende Erstellung einzelner DWriteCore-Objekte verwendet wird.

Hinweis

DWriteCoreCreateFactory ist funktionell identisch mit der DWriteCreateFactory-Funktion, die von der Systemversion von DirectWrite exportiert wird. Die DWriteCore-Funktion hat einen anderen Namen, um Mehrdeutigkeiten zu vermeiden, falls Sie sowohl DWriteCore.lib als auch DWrite.lib verknüpfen.

Referenzinformationen zu DWriteCore und der DirectWrite-API finden Sie unter DWriteCore-API-Referenz und DirectWrite-API-Referenz.

MRTCore

• Die Buildaktion für Ressourcen wird automatisch festgelegt, wenn Sie die Ressource zu Ihrem Projekt hinzufügen – dadurch ist weniger manuelle Projektkonfiguration erforderlich.

Einschränkungen

• Dieses Release wird im Dev-Kanal des Windows-Insider-Programms derzeit nicht unterstützt. Dies wird in Version 0.8.1 behoben.

• Desktop-Apps (C#- oder C++-Desktop): Dieses Release wird nur für die Verwendung in Desktop-Apps (C++ oder C#) unterstützt, die mit MSIX gepackt werden. Um das Windows App SDK in nicht gepackten Desktop-Apps zu verwenden, müssen Sie den experimentellen Releasekanal verwenden.

Wichtig

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

Bekannte Probleme

• WinUI 3-Tools wie Live Visual Tree, Live Property Explorer und Hot Reload in Version 0.8 und höher erfordern Visual Studio 2019 16.11 Preview 3 und höher.

• Apps, die derzeit WinUI 3 und das Windows App SDK 0.8 verwenden, können keine Klassenbibliotheken nutzen, die Project Reunion 0.5 verwenden. Aktualisieren Sie die Klassenbibliotheken, um das Windows App SDK 0.8 zu verwenden.

• .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 Version Ihres Paketprojekts muss auf 18362 oder höher festgelegt sein. Weitere Informationen finden Sie im GitHub-Issue #921.

• Bei einem häufigen Wechsel zwischen hellem und dunklem Modus kann es zu einem Absturz kommt.

• Bei .NET-Apps erhalten Sie möglicherweise den folgenden Fehler, wenn Sie ein Array aus Enumerationen übergeben: Object contains non-primitive or non-blittable data.Dies wird in Version 0.8.2 behoben.

• Für .NET-Apps gibt es derzeit keine Möglichkeit, die Indizierung eines Bilds als App-Ressource über die Visual Studio-Benutzeroberfläche zu deaktivieren. Um dies zu umgehen, fügen Sie dem Projekt eine Directory.Build.targets-Datei hinzu (Anweisungen finden Sie unter Anpassen des Builds – Visual Studio), und entfernen Sie die Bilder wie folgt:

  • So entfernen Sie bestimmte Bilder (beachten Sie, dass der relative Pfad erforderlich ist):

    <Project> 
    <ItemGroup> 
        <Content Remove="..\Bitmap1.bmp" />
    </ItemGroup>
    </Project>
    

  • So entfernen Sie Bilder basierend auf Metadaten:

    <Project>
    <ItemGroup>
        <Content Remove="@(None->WithMetadataValue('Pack','true'))" />
    </ItemGroup>
    </Project>
    

  Eine Behebung dieses Problems ist für ein zukünftiges Release geplant – sobald dies verfügbar ist, werden die oben genannten Problemumgehungen nicht mehr benötigt.

Version 0.5

Die neueste verfügbare Version der 0.5.x-Reihe des stabilen Kanals des Windows App SDK ist Version 0.5.9.

Download

Neue Features und Updates

Dieses Release unterstützt alle Features des stabilen Kanals.

Einschränkungen und bekannte Probleme

Dieses Release weist die folgenden Einschränkungen und bekannten Probleme auf:

• Desktop-Apps (C#- oder C++-Desktop): Dieses Release wird nur für die Verwendung in Desktop-Apps (C++ oder C#) unterstützt, die mit MSIX gepackt werden. Um das Windows App SDK in nicht gepackten Desktop-Apps zu verwenden, müssen Sie den experimentellen Releasekanal verwenden.
• .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.

Wichtig

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

Zugehörige Themen

• Vorschaukanal
• Experimenteller Kanal
• Installieren von Tools für das Windows App SDK
• Erstellen Ihres ersten WinUI 3-Projekts
• Verwenden des Windows-App SDK in einem vorhandenen Projekt
• Bereitstellen von Apps, die das Windows-App SDK verwenden