Notes de publication du canal stable pour le SDK d’application Windows

  • Article

Le canal stable fournit les versions des SDK d’application Windows prises en charge par les applications dans les environnements de production. Les applications qui utilisent la version stable du SDK d’application Windows peuvent également être publiées dans le Microsoft Store.

Les versions suivantes du canal stable sont actuellement disponibles :

Si vous souhaitez mettre à niveau une application existante d’une version antérieure du SDK d’application Windows vers une version plus récente, consultez Mettre à jour des projets existants vers la dernière version du SDK d’application Windows.

Téléchargements pour le SDK d’application Windows

Remarque

Les extensions Windows App Visual Studio Extensions (VSIX) ne sont plus distribuées sous forme de téléchargement séparé. Elles sont disponibles dans le Marché Visual Studio à l'intérieur de Visual Studio.

Version 1.5

Version 1.5.1 (1.5.240311000)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.5.

  • Correction d'un problème où les applications container Apps peuvent ne pas se construire à cause de l'impossibilité de copier « map.html ».
  • Correction d'un problème où MapControl ne parvenait pas à s'initialiser en raison du rejet de jetons valides. Pour plus d'informations, veuillez consulter la section GitHub #9324.
  • Correction d'un problème où MapControl se chargeait avec un fond bleu. Pour plus d'informations, veuillez consulter la section GitHub #9377.
  • Correction d'un problème où le fait de cliquer sur le chevron d'un NavigationViewItem ne permettait pas de l'étendre ou de le réduire correctement en un seul clic. Cela provoquait également l'affichage de menus vides lorsque l'on cliquait sur le chevron en mode PaneDisplayMode="Top". Pour plus d'informations, veuillez consulter les sections GitHub #9423 et #9426.
  • Correction d'un problème où le fait d'appuyer sur un NavigationViewItem avec le doigt ou un stylet empêchait l'élément de répondre à toute saisie ultérieure. Pour plus d'informations, veuillez consulter la section GitHub #9429.
  • Correction d'un problème lorsque vous cliquez sur un élément dans la zone NavigationView.PaneFooter Pour plus d'informations, veuillez consulter la section GitHub #9396.
  • Correction d'un problème où les icônes dans les menus s'affichaient parfois au mauvais endroit. Pour plus d'informations, veuillez consulter la section GitHub #9409.
  • Correction d'un problème où Acrylic ne s'affiche pas dans les menus jusqu'à ce qu'on quitte la fenêtre et qu'on y revienne. Pour plus d'informations, veuillez consulter la section GitHub #9406.
  • Correction d'un plantage qui pouvait se produire lors de l'initialisation de TextBox/RichEditBox. Pour plus d'informations, veuillez consulter la section GitHub #9216.
  • Correction de quelques exceptions bruyantes que NavigationView lançait et capturait lors de sa destruction.
  • Correction d'un problème où un geste « pincer pour zoomer » s'affichait parfois comme un panoramique ou un appui en raison d'un déclenchement incorrect du message PointerCaptureLost.

Version 1.5

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, et les problèmes connus de la version 1.5.

Dans une application existante du SDK d’application Windows 1.4, vous pouvez mettre à jour votre package Nuget vers la version 1.5.240227000 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio en utilisant le Gestionnaire de package NuGet).

Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.

Mises à jour du runtime et de l'arrêt de XAML Islands

Il existe une différence de comportement entre WinAppSDK 1.4 et WinAppSDK 1.5 pour les applications basées sur Xaml Islands lorsque la dernière fenêtre Xaml de n'importe quel thread est fermée.

  • Dans WinAppSDK 1.4, le runtime Xaml quitte toujours la boucle d'événements du thread lorsque la dernière fenêtre Xaml d'un thread est fermée.
  • Dans WinAppSDK 1.5 :
    • Dans le cas d'une application de bureau WinUI, le comportement par défaut reste le même que dans WinAppSDK 1.4.
    • Si vous utilisez Xaml pour l'API DesktopWindowXamlSource (« Xaml Islands »), le comportement par défaut est désormais que Xaml ne quitte pas automatiquement la boucle d'événements du thread.
    • Dans les deux modes, vous pouvez modifier ce comportement en établissant la propriété Application.DispatcherShutdownMode.

Pour en savoir plus, veuillez consulter la documentation relative à la propriété Application.DispatcherShutdownMode lorsqu'elle est disponible. Ceci complète la proposition GitHub n° 8492.

Il existe une différence de comportement entre WinAppSDK 1.4 et WinAppSDK 1.5 pour les applications basées sur XAML Islands en ce qui concerne la durée de vie du runtime XAML :

  • Dans WinAppSDK 1.4, le runtime Xaml s'arrête sur un thread si tous les objets WindowsXamlManager et DesktopWindowXamlSource d'un thread donné sont fermés ou arrêtés, ou si l'exécution de DispatcherQueue sur ce thread est arrêtée (dans ce cas, le runtime Xaml s'arrête pendant la phase DispatcherQueue.FrameworkShutdownStarting).
  • Dans WinAppSDK 1.5, le runtime Xaml ne s'arrête sur un thread que si l'exécution de DispatcherQueue sur ce thread est arrêtée (le runtime XAML s'arrête systématiquement pendant la phase DispatcherQueue.FrameworkShutdownStarting).

Pour en savoir plus, veuillez consulter la documentation relative à la classe WindowsXamlManager lorsqu'elle est disponible.

Il existe une différence de comportement dans WindowsXamlManager.InitializeForCurrentThread() :

  • Dans WinAppSDK 1.4, WindowsXamlManager.InitializeForCurrentThread() renvoie une instance unique d'un objet WindowsXamlManager à chaque appel.
  • Dans WinAppSDK 1.5, WindowsXamlManager.InitializeForCurrentThread() renvoie une instance existante s'il en existe déjà une sur le thread. Close/Dispose() est maintenant ignoré.

Contrôle WinUI Maps

Le contrôle WinUI Maps est maintenant disponible ! Ce contrôle est alimenté par WebView2 et Azure Maps, et fournit les fonctionnalités suivantes :

  • Mouvement panoramique et zoom avec les boutons de la carte ou par interaction tactile.
  • Modification du style de la carte (satellite, relief ou affichage de la rue).
  • Ajout par programmation d'épingles interactives avec des icônes personnalisables par le développeur à la carte.
  • Personnalisation par les développeurs de l'endroit où la carte est centrée lors du chargement initial.
  • Contrôle par les développeurs du masquage ou de l'affichage des boutons de mouvement panoramique, zoom et styles de carte.

WinUI 3 Maps Control

Remarque

Pour utiliser le contrôle Maps, vous aurez besoin d'une clé Azure Maps. Pour créer la clé, consultez la page de documentation Azure Maps sur la création d'une application web.

Le contrôle Maps est entièrement nouveau et nous vous invitons à nous faire part de vos commentaires pour évaluer sa future orientation !

Nouveau contrôle SelectorBar

Dans la version 1.5, nous avons ajouté un nouveau contrôle SelectorBar pour permettre aux utilisateurs de passer d'un affichage de données à un autre. Ce contrôle était précédemment connu sous le nom de « SegmentedControl » sur notre feuille de route 1.5.

WinUI 3 SelectorBar Control

Étiquettes dans les commandes primaires CommandBarFlyout

Les éléments visuels du CommandBarFlyout ont été mis à jour afin d'afficher une étiquette de texte pour les éléments de la zone des commandes principales si la propriété Label a été définie sur le AppBarButton. Auparavant, les commandes primaires de la zone CommandBarFlyout n'affichaient qu'une icône. Désormais, elles peuvent afficher à la fois une icône et un libellé pour une plus grande facilité d'utilisation.

WinUI 3 CommandBarFlyout Labels

Prise en charge de WebView2 pour les environnements et options personnalisés

Le contrôle WinUI WebView2 offre désormais la possibilité de personnaliser l'objet sous-jacentCoreWebView2 à l'aide d'un CoreWebView2Environment et d'un CoreWebView2ControllerOptions personnalisés. Cela permet à l'auteur de l'application de spécifier un autre chemin à partir duquel charger le WebView2Runtime, de choisir d'utiliser un UserDataFolder différent ou de définir des options telles que IsPrivateModeEnabled et ScriptLocale.

Prise en charge de .NET 8

Nous avons ajouté la prise en charge de .NET 8 dans une récente version 1.4 d'entretien, mais celle-ci contenait toujours l'avertissement relatif à l'utilisation de RID spécifiques à la plate-forme. Dans la version 1.5, nous avons achevé ce travail de manière à faire disparaître l'avertissement.

Amélioration du débogage et de la disponibilité des sources

Nous injectons maintenant les informations du serveur de source Github pour le code dans le repo microsoft-ui-xaml dans nos symboles publics, ce qui permet aux débogueurs de télécharger automatiquement le code source. Nous avons également apporté d'autres corrections et améliorations à nos symboles dans l'ensemble du WinAppSDK afin d'améliorer l'expérience de débogage.

Fonctionnalité améliorée pour le débogage des cycles de mise en page

Le débogage des cycles de mise en page dans une application WinUI peut s'avérer difficile. Dans la version 1.5, l'objet DebugSettings expose désormais des options permettant d'activer des journaux et des points d'arrêt améliorés pour le processus de mise en page, afin de faciliter le débogage et la correction des cycles de mise en page dans l'application.

Autres nouvelles fonctionnalités de WinAppSDK

  • Ajout de la prise en charge du modèle de déploiement PublishSingleFile. Pour en savoir plus sur PublishSingleFile, veuillez consulter la documentation relative au déploiement à fichier unique.
  • Amélioration de la prise en charge des lecteurs d'écran, de la mise à l'échelle du texte et d'autres fonctions d'accessibilité.
  • Diverses améliorations de la stabilité et des performances basées sur notre liste de bogues GitHub prioritaires.

Nouvelles fonctionnalités publiées séparément

De nouvelles versions des WinAppSDK Visual Studio Templates pour C# et C++ sont en cours de publication sur le Visual Studio Marketplace et apparaîtront quelques semaines après la sortie de la version 1.5. Avec la nouvelle version, les modèles peuvent désormais être publiés indépendamment des versions du WinAppSDK, ce qui nous offre une plus grande flexibilité dans la distribution des mises à jour aux clients.

Autres fonctionnalités prévues

Dans la version 1.5, nous avons progressé sur les fonctionnalités suivantes que nous avions annoncées sur notre feuille de route, mais que nous n'avons pas achevées. Elles se poursuivront dans la version 1.6.

  • Fenêtres à onglets
  • Prise en charge du glisser-déposer pour WebView2
  • Investigations sur la vue tableau et les contrôles de dessin (ink)

L'éclairage dynamique a été retiré de la feuille de route pour le moment.

Problèmes connus

  • Lorsque vous utilisez des bibliothèques qui contiennent des ressources telles que des fichiers .xaml, vous pouvez rencontrer un message d'erreur au moment de l'exécution indiquant que ces ressources ne peuvent pas être trouvées. Dans ce cas, il peut être nécessaire d'insérer <ShouldComputeInputPris>true</ShouldComputeInputPris> dans le fichier de projet pour s'assurer que ces ressources sont incluses.
  • Cliquer sur le chevron d'un NavigationViewItem ne permet plus de l'agrandir ou de le réduire correctement en un seul clic. Le double-clic fonctionne toujours, de même que le fait de cliquer ailleurs sur le NavigationViewItem

Résolution des bogues

  • Correction d'un problème où StackPanel appliquait un espacement aux éléments réduits. Pour plus d’informations, veuillez consulter la section GitHub #916.
  • Correction de problèmes avec les contrôles de défilement qui ne fonctionnaient plus après la fermeture d'une autre fenêtre de l'application. Pour plus d'informations, consultez les problèmes GitHub #9292 et #9355.
  • Correction d'un crash lors de la définition de DebugSettings.EnableFrameRateCounter à Vrai avant le rendu de la première image. Pour plus d’informations, consultez le problème GitHub 2835.
  • Correction d'une erreur de compilation potentielle pour C++ lorsque certains en-têtes n'incluaient pas les dépendances nécessaires. Notez que le changement de l'ordre #include peut avoir un impact sur certaines applications, en provoquant par exemple une erreur de compilation pour IInspectable si l'application utilise une version de C++/WinRT antérieure à 2023. Pour plus d’informations, veuillez consulter la section GitHub #9014.
  • Correction d'un problème où les liaisons ElementName ne fonctionnaient pas à l'intérieur des ItemsRepeaterDataTemplate. Pour plus d’informations, veuillez consulter la section GitHub #560.
  • Correction de plantages lors de l'exécution d'une application sous Visual Studio avec la barre d'outils in-app activée. Visual Studio 17.8 Preview 2 ou une version ultérieure est nécessaire pour bénéficier pleinement des corrections. Pour plus d’informations, veuillez consulter la section GitHub #8806.
  • Correction d'un problème où AnnotatedScrollbar pouvait parfois se bloquer lors d'un défilement rapide.
  • Correction d'un problème où le texte du menu était parfois tronqué.
  • Résolution d'un problème qui faisait que les conseils pédagogiques n'étaient pas correctement mis en valeur. Pour plus d’informations, veuillez consulter la section GitHub #3257.
  • Résolution d'un problème qui provoquait le plantage de l'application lorsque le TailVisibility d'un TeachingTip était configuré sur Réduit au démarrage. Pour plus d’informations, veuillez consulter la section GitHub #8731.
  • Correction d'un problème concernant la gestion des fichiers PRI lors de l'utilisation de bibliothèques. Pour plus d’informations, veuillez consulter la section GitHub #8857.
  • Résolution d'un problème survenu dans la version 1.5-experimental2, dans laquelle la DLL de projection n'était pas générée. Pour plus d’informations, veuillez consulter la section GitHub #4152.
  • Résolution d'un problème qui faisait que le bouton représentant des points de suspension dans la fenêtre pop-up de mise en forme du texte du RichEditBox n'affichait pas correctement la liste des actions. Pour plus d’informations, veuillez consulter la section GitHub #9140.
  • Résolution d'un problème qui faisait que ListView ne gérait pas correctement les raccourcis clavier. Pour plus d’informations, veuillez consulter la section GitHub #8063.
  • Résolution d'un problème de violation d'accès lors de l'utilisation de AccessKey pour fermer une fenêtre. Pour plus d’informations, veuillez consulter la section GitHub #8648.
  • Correction d'un crash lors de l'utilisation d'un AccessKey pour fermer une fenêtre. Pour plus d’informations, veuillez consulter la section GitHub #9002.
  • Résolution d'un problème affectant l'alignement du texte dans une MenuFlyoutItem au sein d'un MenuBar. Pour plus d’informations, veuillez consulter la section GitHub #8755.
  • Résolution d'un problème qui faisait qu'un texte mis en surbrillance ne le restait pas lors d'un clic droit. Pour plus d’informations, veuillez consulter la section GitHub #1801.
  • Résolution d'un problème qui faisait que les fenêtres inactives entraînaient le plantage de l'application lorsqu'elles étaient fermées. Pour plus d’informations, veuillez consulter la section GitHub #8913.
  • Résolution d'un problème qui pouvait entraîner le blocage des applications en cas de défilement avec le bouton du milieu de la souris suivi d'un clic gauche immédiatement après. Pour plus d’informations, veuillez consulter la section GitHub #9233.
  • Correction d’un problème provoquant des plantages d’applications au démarrage lors de l’utilisation d’un NavigationViewItem personnalisé. Pour plus d’informations, veuillez consulter la section GitHub #8814.
  • Correction d’un problème NavigationView où le bouton des points de suspension générait une erreur. Pour plus d’informations, veuillez consulter la section GitHub #8380.
  • Correction d’un problème où un SystemBackdrop ne s’affichait pas correctement dans une application multi-fenêtres. Pour plus d’informations, veuillez consulter la section GitHub #8423.
  • Correction d’un problème de duplication lors de l’insertion au début d’un ObservableCollection. Pour plus d’informations, veuillez consulter la section GitHub #8370.

Version 1.4

Version 1.4.5 (1.4.240211001)

Il s’agit d’une version de maintenance du SDK d’application Windows qui comprend des correctifs de bogues critiques pour la version 1.4.

  • Résolution d'un problème qui pouvait entraîner le blocage des applications lorsque l'on cliquait tout en faisant défiler avec la roulette de la souris. Pour plus d’informations, veuillez consulter la section GitHub #9233.
  • Résolution d’un problème lié aux ressources en double lors du référencement d’une chaîne de packages NuGet. Pour plus d’informations, veuillez consulter la section GitHub #8857.
  • Résolution de plusieurs BreadcrumbBar problèmes, notamment une fuite de mémoire, un plantage lorsque le menu avec les points de suspension était vide, et le fait que ce menu n'était pas correctement délimité à l'intérieur de la fenêtre.
  • Résolution d’un plantage potentiel à l’arrêt lors de la libération de ressources graphiques.

Version 1.4.4 (1.4.231219000)

Il s’agit d’une version de maintenance du SDK d’application Windows qui comprend des correctifs de bogues critiques pour la version 1.4.

  • Correction d’un problème de sécurité de diagnostic WinUI 3.
  • Correction d’un problème d’entrée où la zone de mot de passe n’affichait pas le clavier visuel lors de l’activation via l’interaction tactile. Pour plus d’informations, consultez le problème GitHub n°8946.
  • Correction d’un problème qui entraînait l’augmentation inattendue de la taille de fichier Microsoft.UI.Xaml.Controls.dll.
  • Correction d’un problème CommandBarFlyout qui pouvait provoquer des blocages lors du réglage de la concentration.
  • Mise à jour de la prise en charge SDK d'application Windows pour la gestion des ressources spécifiques à .NET 8 RID.
  • Correction d’un problème entraînant la position ou l’étirement incorrect de certaines chaînes d’échange.

Version 1.4.3 (1.4.231115000)

Il s’agit d’une version de maintenance du SDK d’application Windows qui comprend des correctifs de bogues critiques pour la version 1.4.

  • Correction d’un problème où un menu pouvait apparaître sans arrière-plan pendant une courte période.
  • Correction d’un incident qui peut se produire dans des scénarios multi-moniteurs spécifiques.
  • Correction d’un problème où un menu contextuel pouvait apparaître hors écran.
  • Correction d’un problème lié aux styles de fenêtre et à l’optimisation du comportement. Pour plus d’informations, consultez le problème GitHub n°8996.
  • Correction d’un problème avec les Islands où le focus pouvait être saisi de manière inattendue à partir d’un autre contrôle.
  • Correction d’un problème lié à l’ordre de tabulation sur NavigationView.
  • Correction d’un problème de rendu où une barre blanche peut être visible en haut de la barre de titre. Pour plus d’informations, consultez le problème GitHub n°8947.
  • Divers correctifs de performances.

Version 1.4.2 (1.4.231008000)

Il s’agit d’une version de maintenance du SDK d’application Windows qui comprend des correctifs de bogues critiques pour la version 1.4.

  • Correction d’un problème de blocage dans explorer.exe provoqué par une allocation excessive de mémoire et d’objets.
  • Correction d’un problème d’interaction de barre de titre qui empêchait le fonctionnement correct du bouton Précédent.
  • Correction d’un problème qui provoquait la génération d’un avertissement quant un fichier source était inclus plusieurs fois.
  • Correction d’un problème affectant les performances du menu contextuel.
  • Correction d’un problème de raccourci .lnk selon lequel le fichier .exe cible pointait toujours vers le même emplacement pour les packages dans le dossier WindowsApps.
  • Correction d’un problème DWriteCore affectant le rendu approprié du texte Indic dans certaines polices.
  • Correction d’un problème dans un affichage Liste qui empêchait la navigation au clavier appropriée vers et depuis les éléments sélectionnés imbriqués avec Tab/Maj + Tab.
  • Correction d’un problème qui rompait le défilement des éléments d’une zone de liste déroulante par fonction tactile après le second développement de la zone de liste déroulante. Pour plus d’informations, consultez le problème GitHub n° 8831.
  • Correction d’un problème selon lequel les packages WinAppSDK n’incluaient pas les ressources localisées de WinUI pour certaines langues.
  • Correction d’une incohérence entre la façon dont l’Explorateur de fichiers et XAML affichent la langue préférée d’un utilisateur.
  • Correction d’un problème dans l’Explorateur de fichiers provoquant l’affichage d’une ligne mince sous l’onglet actif.
  • Correction d’un problème selon lequel certains accélérateurs clavier fournis par l’infrastructure n’étaient pas correctement localisés. Pour plus d’informations, consultez le problème GitHub n°2023.
  • Correction d’un problème qui provoquait le défilement répétitif des contrôles RepeatButton quand ils étaient activés.
  • Correction du fichier .exe du programme d’installation WinAppSDK pour disposer des informations appropriées sur la version des ressources.

Version 1.4.1 (1.4.230913002)

Il s’agit d’une version de maintenance du SDK d’application Windows qui comprend des correctifs de bogues critiques pour la version 1.4.

  • Correction des problèmes de performances pour améliorer le délai d’affichage de la première image.
  • Correction d’un problème où les menus ne respectaient pas RequestedTheme. Par exemple, ce problème pouvait entraîner du texte blanc sur un arrière-plan blanc. Pour plus d’informations, consultez le problème GitHub 8756.
  • Correction d’un problème qui entraînait la transparence totale des arrière-plans acryliques dans certains menus.
  • Correction d’un problème où XAML obligeait parfois Windows à repeindre inutilement le papier peint du bureau.
  • Correction de la prise en charge de TabNavigation = Local et TabNavigation = Cycle pour ListView et GridView, qui permet désormais de naviguer entre les en-têtes et les éléments avec la touche Tabulation en plus des touches de direction.
  • Correction de certaines exceptions bruyantes quand une info-bulle était ignorée. Pour plus d’informations, consultez le problème GitHub 8699.

Version 1.4

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, et les problèmes connus de la version 1.4.

Dans une application existante du SDK d’application Windows 1.3, vous pouvez mettre à jour votre package Nuget vers la version 1.4.230822000 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio en utilisant le Gestionnaire de package NuGet).

Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.

Fusion de la barre de titre personnalisée et de la barre de titre AppWindow

La barre de titre personnalisée WinUI 3 utilise l’implémentation de la barre de titre AppWindow, ainsi que les API NonClientInputPointerSource , sous le capot du SDK d’application Windows 1.4. Par conséquent, les deux implémentations de barre de titre se comportent désormais de la même façon, avec les mêmes fonctionnalités et limitations. Cela est entièrement rétrocompatible dans tous les cas pris en charge : toute application avec une barre de titre personnalisée se comporte comme avant. Toutefois, les développeurs WinUI 3 non familiarisés avec les barres de titre personnalisées peuvent maintenant plus facilement les comprendre et les utiliser en tirant parti de ces nouvelles fonctionnalités :

  • Amélioration du scénario par défaut : le développeur ne définit pas d’élément de barre de titre spécifiquement (remplace la barre de titre de secours de WinUI 2)
  • Régions de glissement distinctes dans la barre de titre, ce qui vous permet de créer plusieurs régions de glissement et de placer des contrôles cliquables n’importe où dans la zone non cliente (zone de barre de titre)
  • Régions de glissement à l’échelle de l’application qui peuvent être placées n’importe où dans l’application ou permettre de faire glisser l’application entière
  • Amélioration de la prise en charge des thèmes qui remplace les thèmes basés sur les ressources
    • Comme les régions de glissement sont transparentes, elles suivent le thème de l’application dans tous les cas
  • Plus de personnalisation : possibilité de masquer les boutons réduire, agrandir et fermer, de placer les icônes système dans la barre de titre, ou d’avoir des régions différentes en guise de boutons légende qui reçoivent des réponses NCHITTEST
  • Plus de liberté pour le développeur qui peut combiner et faire correspondre des API de barre de titre AppWindow. Par exemple, il peut utiliser l’API WinUI 3 de niveau supérieur dans la plupart des scénarios, mais utiliser des API AppWindow mixtes pour un contrôle de niveau inférieur

Mises à jour des widgets

Trois nouvelles interfaces ont été ajoutées pour les fournisseurs de widgets : IWidgetProvider2, IWidgetProviderAnalytics et IWidgetProviderErrors. IWidgetProvider2 permet aux fournisseurs de répondre à l’action Personnaliser appelée par l’utilisateur, comme pour les widgets internes. Les interfaces IWidgetProviderAnalytics et IWidgetProviderErrors sont utilisées par les fournisseurs afin de collecter des données de télémétrie pour leurs widgets ; les événements d’analyse et d’échec sur les widgets sont communiqués aux fournisseurs de widgets respectifs. Les classes WidgetCustomizationRequestedArgs, WidgetAnalyticsInfoReportedArgs et WidgetErrorInfoReportedArgs sont utilisées afin de communiquer des informations pertinentes pour prendre en charge les nouvelles fonctionnalités.

XAML Islands n’est plus expérimental

XAML Islands et la plateforme ContentIslands sous-jacente ne sont plus expérimentaux.

  • Actuellement, XAML Islands est testé uniquement pour les applications C++. Cette version n’a aucun élément de wrapper pratique pouvant être utilisé dans WPF ou WinForms.
  • DesktopWindowXamlSource et les types associés ont été ajoutés dans l’espace de noms Microsoft.UI.Xaml.Hosting pour XAML Islands. XamlRoot.ContentIslandEnvironment a été ajouté pour vous aider à accéder aux informations Island sous-jacentes d’un élément.
  • De nombreux nouveaux types ont été introduits dans l’espace de noms Microsoft.UI.Content et l’espace de noms Microsoft.UI.Input pour la prise en charge sous-jacente de XAML Islands ou pour utiliser cette fonctionnalité ContentIslands sans XAML.
  • Un nouveau DragDropManager (plus les types associés) a été ajouté dans l’espace de noms Microsoft.UI.Input.DragDrop pour les scénarios Island.

ItemsView

Nous introduisons un nouveau contrôle de liste appelé ItemsView et la classe concrète ItemContainer correspondante. ItemContainer est un conteneur léger avec des états de sélection et des visuels intégrés, qui peut facilement encapsuler le contenu souhaité et être utilisé avec ItemsView dans un scénario de contrôle de collection.

  • Le nouveau contrôle ItemsView affiche une collection de données. ItemsView est similaire aux contrôles ListView et GridView, mais est généré à partir des composants ItemsRepeater, ScrollView, ItemContainer et ItemCollectionTransitionProvider. Il offre la possibilité unique de se connecter à des implémentations de Layout ou ItemCollectionTransitionProvider personnalisées. Un autre avantage clé est la possibilité de changer la disposition à la volée tout en préservant la sélection des éléments. Le contrôle interne ScrollView offre également des fonctionnalités non disponibles dans le contrôle ScrollViewer de ListView/GridView, comme la possibilité de contrôler l’animation pendant les défilements programmatiques.
    • Une nouvelle propriété ItemTransitionProvider sur ItemsRepeater (et le nouveau contrôle ItemsView) vous permet de spécifier un objet ItemCollectionTransitionProvider pour contrôler les animations de transition sur ce contrôle. Une méthode CreateDefaultItemTransitionProvider a également été ajoutée à Layout, ce qui permet à un objet de disposition de fournir une transition de secours pour l’accompagner si vous n’en fournissez pas explicitement sur le contrôle ItemsView.
    • Nouvelle propriété IndexBasedLayoutOrientation sur Layout où l’orientation de la disposition, le cas échéant, des éléments est basée sur leur index dans la collection source. La valeur par défaut est IndexBasedLayoutOrientation.None. Les dispositions personnalisées définissent cette propriété en appelant la nouvelle méthode (protégée) SetIndexBasedLayoutOrientation.
    • Une nouvelle propriété VisibleRect sur VirtualizingLayoutContext obtient le rectangle visible de la fenêtre d’affichage dans le FrameworkElement associé à Layout. La méthode virtuelle VirtualizingLayoutContext.VisibleRectCore protégée peut être remplacée pour fournir la valeur que la propriété VisibleRect doit renvoyer.
  • La nouvelle classe LinedFlowLayout est généralement utilisée pour mettre en place les éléments du contrôle de collection ItemsView. Elle est particulièrement utile pour afficher une collection d’images. Elle le fait en les disposant de gauche à droite et de haut en bas, en lignes de hauteur égale. Les images remplissent une ligne horizontale, puis passent à la ligne suivante. Les images peuvent être rognées à gauche et à droite pour s’adapter à une ligne. Elles peuvent également être développées horizontalement, et rognées en haut et en bas pour remplir une ligne quand le mode d’étirement est utilisé.

Nouvelles fonctionnalités de WinAppSDK

  • Nouvelle classe ThemeSettings qui permet aux applications WinRT Win32 de détecter quand le paramètre Contraste élevé du système a changé, comme la classe AccessibilitySettingsUWP. Consultez la Spécification de l’API ThemeSettings sur GitHub pour plus d’informations.
  • AccessKeyManager.EnterDisplayMode est une nouvelle méthode qui affiche les clés d’accès pour l’élément actuel d’une racine fournie ayant le focus. Les touches d’accès sont en « mode d’affichage » quand elles affichent un conseil de touche pour appeler une commande, par exemple, quand vous appuyez sur la touche Alt dans Paint pour afficher les touches qui correspondent aux contrôles. Cette méthode permet d’entrer le mode d’affichage programmatiquement.
  • Application.ResourceManagerRequested fournit un mécanisme pour avoir un autre IResourceManager qui résout les URI de ressource dans les scénarios où le ResourceManager par défaut ne fonctionne pas. Pour plus d’informations, consultez la Spécification de l’API Application.ResourceManagerRequested sur GitHub.
  • Le SDK WebView2 a été mis à jour de la version 1661.34 à la version 1823.32.
  • Popup/FlyoutBase.IsConstrainedToRootBounds = false est désormais pris en charge, ce qui permet à une fenêtre contextuelle/un contrôle suspendu de s’étendre en dehors des limites de la fenêtre parente. Une propriété SystemBackdrop a été ajoutée à ces types pour prendre en charge l’acrylique dans ces fenêtres contextuelles non contraintes. Les menus par défaut utilisent cette option pour avoir l’acrylique.
  • Closed, FrameworkClosed et IsClosed ont été ajoutés à DesktopAcrylicController et MicaController pour améliorer la gestion pendant l’arrêt de l’objet/du thread.
  • DesktopAcrylicController.Kind peut maintenant être défini pour choisir des apparences acryliques standard.
  • DispatcherQueue a de nouveaux événements et applications auxiliaires pour permettre une meilleure organisation de l’arrêt et pour que les applications utilisant Islands puissent exécuter facilement une boucle d’événements prise en charge standard.
  • InputNonClientPointerSource dans l’espace de noms Microsoft.UI.Input peut être utilisé dans les scénarios de barre de titre personnalisé pour définir des régions de zone non cliente. Le code peut s’inscrire à des événements correspondants, comme les événements de pointage et de clic sur ces régions.
  • AppWindow a des nouvelles applications auxiliaires qu’il peut obtenir et associer à un DispatcherQueue.
  • Le nouvel événement TreeView.SelectionChanged permet aux développeurs de répondre quand l’utilisateur ou le code-behind change l’ensemble des nœuds sélectionnés dans le contrôle TreeView.
  • Le nouveau contrôle ScrollView offre une nouvelle alternative à ScrollViewer. Ce nouveau contrôle est hautement aligné en matière de comportement et d’API sur le contrôle existant ScrollViewer, mais est basé sur InteractionTracker, a de nouvelles fonctionnalités comme les changements de vue pilotés par l’animation, et est également conçu pour garantir une fonctionnalité complète de ItemsRepeater. Consultez Un ScrollViewer plus flexible · Problème n° 108 · microsoft/microsoft-ui-xaml (github.com) pour plus d’informations. Différents nouveaux types, y compris ScrollPresenter, font partie du modèle ScrollView général.
  • Le nouveau contrôle AnnotatedScrollBar étend les fonctionnalités d’une barre de défilement classique en fournissant un moyen simple de parcourir une grande collection d’éléments. Le résultat est obtenu en utilisant une barre cliquable avec des étiquettes qui servent de marqueurs. Il permet également une compréhension plus granulaire du contenu de défilement en affichant une info-bulle quand vous pointez sur la barre cliquable.

Problèmes connus

Résolution des bogues

  • Correction d’un problème où l’appel de l’API Microsoft.Windows.AppLifecycle.AppInstance.Restart("") entraînait un blocage des applications non empaquetées. Pour plus d’informations, consultez le problème GitHub 2792.
  • Correction d’un problème de blocage du programme d’installation introduit dans la version 1.4-experimental1. Pour plus d’informations, consultez le problème GitHub 3760.
  • Correction d’un problème où le style barré du texte n’était pas correctement supprimé dans un TextBlock. Pour plus d’informations, consultez le problème GitHub 1093.
  • Correction d’un problème à l’origine d’une navigation Maj + tabulation incorrecte dans un panneau avec TabFocusNavigation défini sur « Une fois ». Pour plus d’informations, consultez le problème GitHub 1363.
  • Correction d’un problème dans C++/WinRT qui empêchait {x:Bind} de fonctionner correctement avec une propriété d’un contrôle XAML nommé. Pour plus d’informations, consultez le problème GitHub 2721.
  • Correction d’un problème AccessViolation du runtime dans les applications de bureau WinUI provoqué par la définition de DebugSettings.EnableFrameRateCounter = true. Pour plus d’informations, consultez le problème GitHub 2835.
  • Correction d’un problème où XamlTypeInfo.g.cpp il n’avait pas les en-têtes nécessaires. Pour plus d’informations, consultez le problème GitHub 4907.
  • Correction d’un problème de blocage provoqué par une entrée de la souris et une entrée tactile multipoint effectuées simultanément. Pour plus d’informations, consultez le problème GitHub 7622.
  • Correction d’un problème empêchant le défilement d’une fenêtre d’application WinUI 3 active quand le paramètre système pour désactiver le défilement des fenêtres inactives sur la souris était en vigueur. Pour plus d’informations, consultez le problème GitHub 8764.
  • Correction d’un blocage pendant la tentative de création d’une sous-classe de MediaPlayerElement.
  • Correction de problèmes de blocage et de fuite de mémoire dans TreeView.
  • Correction d’un problème de blocage d’application qui pouvait se produire pendant l’utilisation du clavier pour naviguer dans RadioButtons.
  • Correction d’un blocage pendant l’utilisation du clavier pour naviguer dans un PipsPager.
  • Correction du contenu WebView2 pour qu’il se mette à l’échelle avec le paramètre d’accessibilité « Taille du texte » dans l’application Paramètres.
  • Correction d’un blocage pouvant se produire quand les animations étaient en cours d’exécution alors que l’affichage était désactivé.
  • Correction d’un problème de performances introduit dans la version 1.3 qui ajoutait une surcharge d’environ 10 % à la première disposition/au premier rendu.

Version 1.3

Version 1.3.3 (1.3.230724000)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.3.

  • Correction d’un problème où la souris cessait parfois de fonctionner quand une boîte de dialogue était fermée.
  • Correction d’un problème de déploiement qui empêchait l’installation des applications en raison d’une incompatibilité des versions de package sur le système. Pour plus d’informations, consultez le problème GitHub 3740.
  • Correction d’un problème affectant le positionnement du menu contextuel dans le SDK d’application Windows 1.3.
  • Correction d’un problème entraînant le blocage de certaines applications WinUI3, dans certains cas, pendant la fermeture de l’application, car XAML s’arrêtait trop tôt.
  • Correction d’un problème où les icônes de police n’étaient pas correctement mises en miroir dans les langues de droite à gauche. Pour plus d’informations, consultez le problème GitHub 7661.
  • Correction d’un problème entraînant le blocage d’une application à l’arrêt quand les ressources étaient détruites dans le mauvais ordre. Pour plus d’informations, consultez le problème GitHub 7924.

Version 1.3.2 (1.3.230602002)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.3.

  • Correction d’un plantage au moment de la définition d’un curseur protégé.
  • Correction d’un problème de performances dans XamlMetadataProvider au démarrage d’une application. Pour plus d’informations, consultez le problème GitHub #8281.
  • Correction d’un problème lié aux liens hypertexte et à l’interaction tactile dans un RichTextBlock. Pour plus d’informations, consultez le problème GitHub #6513.
  • Correction d’un problème lié au défilement et aux pavés tactiles dans WebView2. Pour plus d’informations, consultez le problème GitHub #7772.
  • Correction d’un problème rendant parfois nécessaire le redémarrage de Visual Studio quand le SDK d’application Windows est mis à jour. Pour plus d’informations, consultez le problème GitHub #3554.
  • Correction d’une exception bruyante à l’arrêt en cas d’exécution dans un débogueur.

Version 1.3.1 (1.3.230502000)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.3.

  • Correction d’un problème provoquant le blocage des applications lors de la définition de SystemBackdrop si le contenu était null. Pour plus d’informations, consultez le problème GitHub #8416.
  • Résolution d’un problème provoquant le blocage des applications lors de la définition du titre de la fenêtre en XAML, une nouvelle fonctionnalité ajoutée dans la version 1.3.0. Pour plus d’informations, consultez le problème GitHub #3689.
  • Correction d’un problème où une fenêtre prenait le focus de manière incorrecte lorsque son contenu changeait.
  • Correction d’un problème lié à la création de projets C++ avec les modèles de projet WinAppSDK 1.3.
  • Modèles mis à jour sur la Place de marché Visual Studio

Version 1.3

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour et les problèmes connus pour la version 1.3.

Dans une application du SDK d’application Windows 1.2 existante, vous pouvez mettre à jour votre package Nuget vers la version 1.3.230331000 (voir la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l’aide du Gestionnaire de package NuGet).

Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.

API de toile de fond XAML

Avec les propriétés intégrées à la fenêtre XAML, les toiles de fond Mica et arrière-plan Acrylic sont désormais plus faciles à utiliser dans votre application WinUI 3. Pour plus d’informations sur les propriétés de toile de fond Xaml, consultez la documentation sur la Toile de fond système et l’API de Toile de fond Mica.

public MainWindow()
{
    this.InitializeComponent();

    this.SystemBackdrop = new MicaBackdrop();
}

Window.AppWindow

En remplaçant plusieurs lignes de code réutilisable, vous pouvez maintenant utiliser les API AppWindow directement à partir d’une fenêtre via Window.AppWindow.

Nouvelles fonctionnalités de WinAppSDK

  • ApplicationModel.DynamicDependency : PackageDependency.PackageGraphRevisionId qui remplace le MddGetGenerationId déprécié.
  • Gestionnaire d’environnement : EnvironmentManager.AreChangesTracked pour vous informer si les modifications apportées au gestionnaire d’environnement peuvent être suivies dans votre application.
  • Un nouvel événement, DebugSettings.XamlResourceReferenceFailed, est maintenant déclenché lorsqu’une recherche Static/ThemeResource référencée ne peut pas être résolue. Cet événement donne accès à une trace qui détaille l’emplacement où le cadre a recherché cette clé afin de mieux vous permettre de déboguer les échecs de recherche de Static et ThemeResource. Pour plus d’informations, consultez la spécification de l’API Échecs de recherche de ressources XAML de suivi sur GitHub.

Autres mises à jour

  • Consultez notre jalon WinAppSDK 1.3 sur le GitHub WinAppSDK pour connaître les problèmes supplémentaires résolus dans cette version.
  • Consultez notre jalon WinUI 3 dans WinAppSDK 1.3 sur le GitHub microsoft-ui-xaml pour connaître les problèmes supplémentaires traités dans cette version.
  • Avec la dernière version expérimentale de VSIX, vous pouvez désormais convertir votre application entre les formats non empaqueté et empaqueté via le menu Visual Studio au lieu d’avoir à passer par votre fichier projet.

Problème connu

En raison d’une modification récente du compilateur xaml, un projet existant qui effectue une mise à niveau vers la version 1.3 peut rencontrer une erreur de build comme celle-ci dans Visual Studio :

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

Cela est causé par l’utilisation par Visual Studio d’une dll de tâche de compilateur xaml mise en cache de la version 1.2 avec une logique MSBuild incompatible de la version 1.3, comme indiqué dans le texte d’erreur ci-dessus. La solution de contournement consiste à arrêter Visual Studio, à le redémarrer et à recharger la solution.

Version 1.2

Version 1.2.5 (1.2.230313.1)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.2.

  • Résolution d’un problème provoquant le blocage des applications lors de l’arrêt de la composition.
  • Résolution d’un problème entraînant la poursuite de l’exécution des animations par les applications même lorsque l’écran est éteint.
  • Correction d’un problème entraînant l’échec de l’entrée de la souris et de l’entrée tactile dans WebView2 lorsque l’entrée de la souris et celle clavier se produisaient simultanément. Pour plus d’informations, consultez le problème GitHub #3266.

Version 1.2.4 (1.2.230217.4)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.2.

  • Résolution d’un problème empêchant les applications autonomes de définir les paramètres de contrôle d’utilisateur. Pour plus d’informations, consultez le problème GitHub #3376.
  • Correction d’un problème entraînant le retour d’un délai d’expiration incorrect par les notifications push avec PushNotificationChannel::ExpirationTime. Pour plus d’informations, consultez le problème GitHub #3300.
  • Correction d’un problème qui faisait que les nombres négatifs étaient considérés comme « non valides » lors du passage d’un double en tant que paramètre dans une fonction x:Bind.
  • Plusieurs correctifs pour mettre à jour le VSIX WinUI. Ces mises à jour comprenaient la simplification du dipAwareness du modèle de projet dans app.manifest, la suppression des modèles UWP, la mise à jour des fichiers de ressources localisés, l’ajout de l’ID de téléphone pour débloquer la soumission au Store et la suppression de l’avis de droits d’auteur et de la licence. Pour plus d’informations, consultez les problèmes GitHub #5659, #3205, #3323, #3322 et #3143.

Version 1.2.3 (1.2.230118.102)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.2.

  • Résolution d’un problème provoquant le blocage des applications WinUI 3 lorsque plusieurs fenêtres sont fermées.
  • Résolution d’un problème provoquant un blocage lors de la fermeture de l’application lorsque deux références ou plus à l’interface ThreadPoolTimer sont appelées. Pour plus d’informations, consultez les problèmes GitHub #7260 et #7239.
  • Résolution d’un problème entraînant l’exécution de toutes les applications MSIX à projet unique avec la confiance totale. Pour plus d’informations, consultez le problème GitHub #7766.

Version 1.2.2 (1.2.221209.1)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.2.

  • Correction du problème qui entraînait l’échec de l’installation des packages Store et side-load (par exemple, à partir du programme d’installation, de NuGet et du programme d’amorçage) si l’autre était déjà installé. Pour plus d’informations, consultez le problème GitHub #3168.
  • Correction d’un problème entraînant l’absence d’effets d’élasticité et de courbes d’animation lors du défilement avec un pavé tactile. Pour plus d’informations, consultez le problème GitHub #7874.
  • Résolution d’un problème dans ListView provoquant des fuites de mémoire.
  • Résolution d’un problème entraînant le non-respect de la propriété Foreground par le modèle Button après le pointage de la souris. Pour plus d’informations, consultez le problème GitHub #7208.
  • Correction d’un problème provoquant une exception inutile lorsqu’il n’y a pas de MediaPlaybackItem dans un élément MediaElement.
  • Correction d’un problème entraînant l’affichage d’un cadre blanc dans MediaPlayerElement lors des transitions de contenu.
  • Correction de problèmes supplémentaires empêchant App.UnhandledException d’intercepter les exceptions d’autres threads. Pour plus d’informations, consultez les problèmes GitHub #1259 et #5221.

Version 1.2.1 (1.2.221116.1)

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut un correctif de bogue critique pour la version 1.2.

Correction d’un problème qui provoquait un blocage au démarrage dans les applications WinUI 3 C++ lors de l’ajout d’un contrôle WebView2 ou TextBox. Pour plus d’informations, consultez les problèmes GitHub #7911 et #3117.

Version 1.2

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour la version 1.2.

Notes

Visual Studio 2019 et .NET 5 ne sont plus pris en charge pour la création d’applications C# (voir Passage du SDK d’application Windows 1.2 à C# WinRT 2.0). Vous aurez besoin de Visual Studio 2022 et de l’une des versions suivantes du SDK .NET : 6.0.401 (ou version ultérieure), 6.0.304 ou 6.0.109. Une fois disponible, WinAppSDK 1.2 prendra également en charge .NET 7.

Pour mettre à jour votre version du SDK .NET, installez la dernière version de Visual Studio 2022 ou visitez les Téléchargements .NET. Lors de la mise à jour de votre package NuGet sans la version requise du SDK .NET, vous verrez une erreur comme : « Cette version de WindowsAppSDK nécessite .NET 6+ et WinRT.Runtime.dll version 2.0 ou ultérieure ». Pour mettre à jour le projet de .NET 5.0 vers .NET 6.0, ouvrez le fichier projet et remplacez « TargetFramework » par net6.0 et « Target OS version » par la valeur appropriée (par exemple net6.0-windows10.0.19041.0).

Widgets tiers dans Windows

Le tableau de widgets a été introduit pour la première fois dans Windows 11 et se limitait à l’affichage des widgets intégrés. Les widgets sont de petits conteneurs d’interface utilisateur qui affichent du texte et des graphiques sur le tableau de widgets, associés à une application installée sur l’appareil. Avec le SDK d’application Windows, en tant que développeurs tiers, vous pouvez désormais créer des widgets pour vos applications Win32 empaquetées et les tester localement sur le tableau de widgets Windows 11.

Pour plus d’informations sur les widgets, consultez Vue d’ensemble des widgets.

Pour commencer à développer des widgets pour votre application, consultez les documents de développement pour les fournisseurs de services de widget et les principes de base de conception de widgets pour les prérequis, des conseils et les meilleures pratiques.

Les prérequis pour cette version comprennent les suivants :

  • Mode développeur activé sur l’ordinateur de développement.
  • L’ordinateur de développement doit exécuter une version de Windows du canal de développement de Windows Insider Preview (WIP) supérieure ou égale à 25217 avec le tableau de widgets version 521.20060.1205.0 ou ultérieure.

Limitations connues lors du développement de widgets

  • Les widgets tiers ne peuvent être testés localement que sur les appareils inscrits dans WIP pour cette préversion.
  • Les widgets ne peuvent être créés que pour les applications Win32 empaquetées. Les widgets pour les applications web progressives (PWA) devraient être pris en charge dans le cadre de Microsoft Edge 108.

DisplayInformation

Les applications de bureau Windows peuvent désormais prendre en charge la plage dynamique étendue (HDR) et la gestion automatique des couleurs (ACM) via la classe DisplayInformation dans WinAppSDK. La classe DisplayInformation vous permet de surveiller les informations relatives à l’affichage d’une vue d’application. Cela inclut les événements permettant aux clients de surveiller les modifications apportées à la vue de l’application affectant les affichages sur lesquels réside la vue, ainsi que les modifications apportées aux affichages qui peuvent affecter la vue de l’application.

WinUI 3

Les applications WinUI 3 peuvent lire de l’audio et de la vidéo avec les contrôles de lecture multimédia MediaPlayerElement et MediaTransportControls. Pour plus d’informations sur l’utilisation et le moment auquel utiliser des contrôles multimédias, consultez Lecteurs multimédias.

WinUI 3 a été mis à jour avec les derniers contrôles, styles et comportements de WinUI 2.8. Ces mises à jour incluent l’ajout du contrôle InfoBadge, des améliorations de l’accessibilité et du mode de contraste élevé, ainsi que des correctifs de bogues à travers les contrôles. Pour plus d’informations, consultez les notes de publication pour WinUI 2.7 et WinUI 2.8.

Problèmes résolus

Limitations connues

  • Lors de la création d’un projet WinUI 3 avec Visual Studio 2022 17.4.0, il référence une version en préversion de WinAppSDK. Utilisez le Gestionnaire de package NuGet pour mettre à jour la référence vers cette version.
  • La définition de MediaPlayerElement.Source sur l’URI relatif (ms-appx/ms-resource) échoue dans les applications non empaquetées. La solution de contournement recommandée consiste à convertir l’URI ms-appx:/// relatif en URI file:/// entièrement résolu.

Découpage pour les applications développées avec .NET

Les développeurs .NET peuvent désormais publier des applications WinAppSDK découpées. Avec CsWinRT 2.0, les projections C#/WinRT distribuées dans WinAppSDK sont désormais modifiables. La publication de votre application découpée peut réduire l’empreinte disque de votre application en supprimant tout code inutilisé des fichiers binaires découpables. Les applications peuvent également ainsi voir une amélioration des performances au démarrage. Avec une application Hello World de base, nous avons constaté une amélioration de l’empreinte disque d’environ 80 % et une amélioration des performances au démarrage d’environ 7 % lors de la publication de la version découpée. Avec la galerie WinUI, nous avons constaté une amélioration de l’empreinte disque d’environ 45 %.

Pour plus d’informations sur la façon d’activer le découpage, les limitations du découpage (comme la réflexion sur les types pouvant être découpés) et les avertissements de découpage, consultez Couper les déploiements et exécutables autonomes. Les développeurs doivent tester minutieusement leurs applications après le découpage pour s’assurer que tout fonctionne comme prévu. Pour plus d’informations, consultez le problème 2478 sur GitHub.

Prise en charge de Visual Studio Arm64

Dès Project Reunion (désormais WinAppSDK) 0.5, les applications développées avec WinAppSDK pouvaient s’exécuter sur Arm64. À partir de Visual Studio 17.3 Preview 2, vous pouvez développer des applications natives avec WinAppSDK sur des appareils Arm64.

Pour commencer à développer sur un appareil Arm64, consultez Windows sur Arm et Arm64 Visual Studio.

Notifications

AppNotificationBuilder a été introduit comme alternative à la charge utile XML pour la création et la définition de notifications d’application.

Pour plus d’informations sur son utilisation, consultez la spécification AppNotificationBuilder sur GitHub.

Consultez également Démarrage rapide : Notifications d’application dans le SDK d’application Windows pour obtenir un exemple de création d’une application Windows de bureau qui envoie et reçoit des notifications d’application locale.

Modification critique

Pour les notifications push, lors d’un appel de requête de canal, les applications doivent utiliser l’ID d’objet Azure au lieu de l’ID d’application Azure. Pour plus d’informations sur la recherche de votre ID d’objet Azure, consultez Démarrage rapide : Notification push dans le SDK d’application Windows.

Problème résolu

PushNotificationManager.IsSupported vérifie l’utilisation du mode avec élévation de privilèges. Elle retourne false si l’application a des privilèges élevés.

Limitations connues (notifications)

  • Dans AppNotificationScenario, Urgent est uniquement pris en charge pour les builds Windows 19041 et ultérieures. Vous pouvez utiliser AppNotificationBuilder.IsUrgentScenarioSupported pour vérifier si la fonctionnalité est disponible au moment de l’exécution.
  • Dans AppNotificationButton, hint-toolTip et hint-buttonStyle sont uniquement pris en charge pour les builds 19041 et ultérieures. Vous pouvez utiliser IsButtonStyleSupported et IsToolTipSupported pour vérifier si la fonctionnalité est disponible au moment de l’exécution.
  • Dans MediaPlayerElement, lorsqu’elle est utilisée dans le balisage XAML pour une application non empaquetée, la propriété Source ne peut pas être définie avec un URI ms-appx ou ms-resource. Vous pouvez également définir la source à l’aide d’un URI de fichier ou à partir du code.

Fenêtrage

La personnalisation complète de la barre de titre est désormais disponible sur Windows 10, version 1809 et versions ultérieures via la classe AppWindowTitleBar. Vous pouvez définir AppWindowTitleBar.ExtendsContentIntoTitleBar sur true pour étendre le contenu dans la zone de barre de titre, et SetDragRectangles pour définir des régions de glissement (en plus d’autres options de personnalisation).

Si vous avez utilisé la propriété AppWindowTitleBar.IsCustomizationSupported pour vérifier si vous pouvez appeler les API AppWindowTitleBar, elle retourne désormais true sur les versions du SDK d’application Windows pour Windows 10 prises en charge (1809 et versions ultérieures).

Limitations connues (fenêtrage)

Les personnalisations de base de la barre de titre ne sont pas prises en charge sur Windows 10. Cela comprend BackgroundColor, InactiveBackgroundColor, ForegroundColor, InactiveForegroundColor et IconShowOptions. Si vous appelez ces propriétés, elles seront ignorées sans avertissement. Toutes les autres API AppWindowTitleBar fonctionnent dans Windows 10, version 1809 et versions ultérieures. Pour les API de couleur de bouton de légende (entre autres) et Height, ExtendsContentIntoTitleBar doit avoir la valeur true, sinon ces valeurs seront également ignorées sans avertissement.

Contrôle d’accès

Introduction de security.accesscontrol.h avec la fonction GetSecurityDescriptorForAppContainerNames pour faciliter et simplifier le partage d’objets nommés entre les processus empaquetés et les API Win32 générales. Cette méthode prend une liste de noms de famille de packages (PFN) et de masques d’accès, puis retourne un descripteur de sécurité. Pour plus d’informations, consultez la spécification GetSecurityDescriptorForAppContainerNames sur GitHub.

Autres limitations et problèmes connus

Important

Lorsque vous référencez WinAppSDK 1.2 à partir d’un projet, vous pourriez voir une erreur semblable à : « Rétrogradation de package détectée : Microsoft.Windows.SDK.BuildTools de 10.0.22621.1 à 10.0.22000.194 », qui est provoquée par des références incompatibles au package du projet d’application et du package WinAppSDK. Pour résoudre ce problème, vous pouvez mettre à jour la référence dans le projet vers une version plus récente et compatible de Microsoft.Windows.SDK.BuildTools.

  • Les tests unitaires peuvent échouer avec une erreur REGDB_E_CLASSNOTREG dans le volet Sortie des tests dans Visual Studio. Pour contourner ce problème, vous pouvez ajouter <WindowsAppContainer>true</WindowsAppContainer> à votre fichier projet.
  • PublishSingleFile .NET n’est pas pris en charge.
  • Les valeurs par défaut de l’initialiseur automatique WinRT RegFree et Bootstrapper RegFree sont (maintenant) définies uniquement pour les projets qui produisent un exécutable (OutputType=Exe ou WinExe). Cela empêche l’ajout d’initialiseurs automatiques dans des DLL de bibliothèques de classes et d’autres fichiers non exécutables par défaut.
    • Si vous avez besoin d’un initialiseur automatique dans un non-exécutable (par exemple, une DLL de test chargée par un exécutable générique qui n’initialise pas le Bootstrapper), vous pouvez activer explicitement un initialiseur automatique dans votre projet via <WindowsAppSdkBootstrapInitialize>true</WindowsAppSdkBootstrapInitialize> ou <WindowsAppSdkUndockedRegFreeWinRTInitialize>true</WindowsAppSdkUndockedRegFreeWinRTInitialize>.
  • Microsoft.WindowsAppRuntime.Release.Net.dll est toujours le binaire Arm64 et ne fonctionne pas pour les applications x86 et x64. Lorsque vous appelez explicitement l’API Bootstrap, n’utilisez pas l’assembly Microsoft.WindowsAppRuntime.Release.Net.dll. Pour contourner ce problème, vous pouvez inclure des constantes de version dans ce fichier source distribué avec le package NuGet : « ..\include\WindowsAppSDK-VersionInfo.cs » ou utiliser l’initialiseur automatique.

Version 1.1

La dernière version disponible de la traçabilité 1.1.x du canal stable du SDK d’application Windows est la version 1.1.5. 1.1.x prend en charge toutes les fonctionnalités du canal stable (voir la section Fonctionnalités disponibles par canal de publication des Canaux de publication du SDK d’application Windows).

Version 1.1.5

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.1.

Résolution des bogues

  • Correction du problème où Acrylic ne fonctionne pas si Mica est activé. Pour plus d’informations, consultez le problème 7200 sur GitHub.
  • Résolution d’un problème entraînant l’échec de l’exécution des applications qui dépendent du programme d’installation WindowsAppRuntime (par exemple, les applications non empaquetées) sur les machines Windows 10 ARM64. Pour plus d’informations, consultez le problème 2564 sur GitHub.

Version 1.1.4

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.1.

Résolution des bogues

  • Correction de la régression de la version 1.0.x, provoquant le blocage de ListView, TreeView et d’autres contrôles « List » lors du défilement avec de nombreux éléments. Pour plus d’informations, consultez le problème 7230 sur GitHub.
  • Résolution d’un problème lié à DispatcherQueue qui empêchait l’appel des rappels en file d’attente.
  • Résolution d’un problème provoquant le blocage d’une application lors de l’appel à DeploymentManager.Initialize plusieurs fois dans la même session d’application.
  • Résolution d’un problème entraînant l’échec de la génération d’applications C# sur Visual Studio Arm64. Pour plus d’informations, consultez le problème 7140 sur GitHub.
  • Correction d’un incident intermittent dans le code d’imagerie XAML en raison d’une gestion incorrecte des défaillances.
  • Correction d’un problème de fuite de mémoire lors de l’attachement d’un gestionnaire d’événements dans ItemsRepeater à un UserControl parent. Pour plus d’informations, consultez le problème 6123 sur GitHub.
  • Correction d’un problème provoquant un échec de build dans Visual Studio 17.3 lorsqu’un projet d’application est configuré pour activer les mises à jour automatiques de son package lorsqu’il est chargé de manière indépendante (par exemple .appinstaller). Pour plus d’informations, consultez le problème 2773.
  • Correction d’un problème entraînant des appels redondants par les applications empaquetées distribuées par le Store qui appellent Initialize (nécessaire, par exemple, pour Push), car DeploymentManager::GetStatus retournait Package Install Needed quand les packages main et singleton étaient déjà installés. Cela provoquait une dégradation des performances au lancement de l’application.
  • Correction d’un problème provoquant une exception dans les applications à instance unique lorsque l’événement de nettoyage devait être ignoré s’il ne pouvait pas être ouvert. Pour plus d’informations, consultez la demande de tirage sur GitHub.

Version 1.1.3

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.1.

Résolution des bogues

  • Correction d’un ensemble connexe de problèmes où XAML se bloquait lors de l’inclusion d’un contrôle ProgressBar, ProgressRing, PipsPager, PersonPicture ou Expander dans la première page de votre application. Pour plus d’informations, consultez le problème 7164 sur GitHub.
  • Correction d’un problème entraînant l’échec de l’installation du programme d’installation x64 du runtime du SDK d’application Windows. Pour plus d’informations, consultez le problème 2713 sur GitHub.
  • Correction d’un problème entraînant l’échec de l’installation de WindowsAppRuntime si une version supérieure du runtime était installée. Pour plus d’informations, consultez la discussion 2708 sur GitHub.

Version 1.1.2

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.1.

Résolution des bogues

  • Résolution d’un problème lié au blocage de XAML lors de la fermeture d’une fenêtre alors qu’une boîte de dialogue était ouverte. Pour plus d’informations, consultez le problème 1032 sur GitHub.
  • Ajout d’une balise <auto-generated> dans les fichiers C# pour empêcher les avertissements StyleCop. Pour plus d’informations, consultez le problème 4526 sur GitHub.
  • Correction d’un problème provoquant une erreur de violation d’accès et un plantage lors de l’appel de MddBootstrapInitialize lorsque le package d’infrastructure correspondant n’était pas installé. Pour plus d’informations, consultez le problème 2592 sur GitHub.
  • Correction du problème où les modèles d’élément WinUI 3 C# étaient manquants dans Visual Studio. Pour plus d’informations, consultez le problème 7148 sur GitHub.
  • Correction du problème où le programme d’installation de WindowsAppRuntime échouait lors de l’exécution en tant qu’utilisateur système. Pour plus d’informations, consultez le problème 2546 sur GitHub.

Version 1.1.1

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.1.

Résolution des bogues

  • Correction d’un problème entraînant parfois le blocage des applications lors d’une opération de glisser-déplacer. Pour plus d’informations, consultez le problème 7002 sur GitHub.
  • Correction d’un problème entraînant la disparition de la barre de titre lors du basculement d’AppWindowPresenterKind de FullScreen à Default.
  • Correction d’un problème où les API Bootstrapper comme ApiInformation.IsPropertyPresent et ApiInformation.IsMethodPresent provoquaient des exceptions non gérées dans les applications qui n’étaient pas empaquetées. Pour plus d’informations, consultez le problème 2382 sur GitHub.
  • Résolution d’un problème provoquant le blocage de l’application lors de l’optimisation de l’application avec une entrée de stylet.

Version 1.1

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour la version 1.1.

Notes

Pour les développeurs C#, l’une des versions suivantes du SDK .NET est requise : 6.0.202, 6.0.104, 5.0.407, 5.0.213 (ou version ultérieure). Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio. Sans la version requise du SDK .NET, lors de la mise à jour de votre package NuGet, vous verrez une erreur du type : « Cette version de WindowsAppSDK nécessite WinRT.Runtime.dll version 1.6 ou ultérieure ».

Redémarrage et cycle de vie des applications

Les applications sont désormais en mesure de lancer un redémarrage explicite avec des arguments et un état spécifiques qui s’appuient sur l’API RegisterApplicationRestart existante pour s’inscrire auprès du système d’exploitation pour redémarrer dans les scénarios de mise à jour et de blocage et de redémarrage.

Nouvelles fonctionnalités :

  • Toute application de bureau empaquetée ou non empaquetée peut se terminer et redémarrer elle-même sur commande, et avoir accès à une chaîne de ligne de commande arbitraire pour l’instance redémarrée à l’aide de l’API AppInstance.Restart().
    • Il s’agit d’une version liftée et synchrone de l’API UWP RequestRestartAsync() qui permet le redémarrage avec des arguments et retourne une AppRestartFailureReason si le redémarrage échoue.
    • Consultez la documentation sur Restart API sur GitHub pour obtenir des informations de référence et d’utilisation.

WinUI 3

WinUI 3 est le framework d’expérience utilisateur natif pour le SDK d’application Windows. Cette version inclut de nouvelles fonctionnalités de WinAppSDK 1.0, ainsi que plusieurs améliorations de stabilité à partir des aperçus 1.0 et 1.1.

Nouvelles fonctionnalités :

  • Mica et Acrylic sont désormais disponibles pour les applications WinUI 3.
  • Fonctionnalité introduite pour la première fois dans la version 1.0.1, nous avons stabilisé et activé la création de plusieurs fenêtres sur le même thread dans les applications WinUI 3. Pour plus d’informations, consultez le problème 5918.

Bogues résolus :

  • Résolution d’un problème lors de l’utilisation de Mica où l’application se bloquait lorsqu’une fenêtre était divisée de façon égale par deux écrans. Pour plus d’informations, consultez le problème 7079 sur GitHub.
  • Résolution d’un problème entraînant le blocage des applications C# avec WebView2 au lancement lorsque le runtime C/C++ (CRT) n’était pas installé en mettant à niveau le SDK WebView2 de la version 1020.46 vers la version 1185.39.
  • Correction d’un problème entraînant l’affichage d’un dégradé dans certains coins arrondis alors qu’ils devaient être de couleur unie. Pour plus d’informations, consultez les problèmes 6076 et problèmes 6194 sur GitHub.
  • Correction d’un problème où les styles mis à jour étaient manquants dans generic.xaml.
  • Correction d’un problème de cycle de disposition provoquant le blocage d’une application lors du défilement jusqu’à la fin d’un contrôle ListView. Pour plus d’informations, consultez le problème 6218 sur GitHub.
  • Résolution d’un problème où les utilisateurs ne pouvaient pas déplacer un élément lorsque le glisser-déplacer était activé. Pour plus d’informations, consultez le problème 7008 sur GitHub.

Limitations connues :

  • Lors de l’utilisation d’une barre de titre personnalisée, les contrôles légende ne changeaient pas de couleur lors du changement de thème.
  • XAML se bloquait lorsqu’un utilisateur ferme une fenêtre alors qu’une boîte de dialogue est ouverte.

Déploiement

Nouvelles fonctionnalités :

Limitations connues :

  • L’exécution du programme d’installation du runtime d’application Windows (WindowsAppRuntimeInstall.exe) nécessite l’activation du chargement indépendant. Pour plus d’informations, consultez le problème 2469 sur GitHub.
  • La création d’un package MSIX via les menus de projet Visual Studio peut bloquer Visual Studio dans certains scénarios. Ce problème sera résolu dans Visual Studio version 17.3 Preview 2 et corrigé dans la version 17.2. Si vous rencontrez ce problème, vous pouvez le contourner en générant un MSIX à partir de la ligne de commande, en basculant vers un projet non empaqueté ou en revenant au SDK d’application Windows 1.0.
  • Les applications autonomes empaquetées avec MSIX ne sont pas prises en charge avec la version 1809, ce qui entraîne un blocage de l’application au lancement.

Elevation

Les applications peuvent désormais s’exécuter avec des privilèges élevés.

Limitations connues :

Gestionnaire de variables d’environnement

Le Gestionnaire de variables d’environnement est une nouvelle API introduite dans le SDK d’application Windows 1.1. Le Gestionnaire de variables d’environnement permet aux développeurs d’accéder aux variables d’environnement et de les modifier dans l’étendue du processus, de l’utilisateur et de la machine à partir d’une seule surface d’API.

Si le Gestionnaire de variables d’environnement est utilisé à partir d’une application empaquetée, toutes les opérations de variable d’environnement sont enregistrées. Lorsque le package est supprimé, toutes les opérations de variable d’environnement sont annulées.

Nouvelles fonctionnalités :

  • Obtenez et définissez des variables d’environnement dans l’étendue du processus, de l’utilisateur et de l’ordinateur.
  • La variable d’environnement automatique est rétablie lorsqu’un package qui utilise le gestionnaire de variables d’environnement est supprimé.
  • Inclut des API spécifiques pour PATH et PATHEXT.

Limitations connues :

  • Disponible uniquement sur Windows 11

MRT Core

MRT Core est une version simplifiée du système de gestion des ressources Windows moderne qui est distribué dans le cadre du SDK d’application Windows.

Problèmes résolus :

  • Un problème empêchant l’indexation des ressources par défaut lorsqu’un fichier de ressources est ajouté à l’aide de l’interface utilisateur de Visual Studio est résolu dans le SDK .NET 6.0.300. Si vous utilisez une version antérieure du SDK .NET, continuez à utiliser la solution de contournement décrite dans les notes de publication de la version 1.0. Pour plus d’informations, consultez le problème 1786 sur GitHub.
  • Un problème empêchant la génération correcte de l’URI de ressource dans les applications WinUI 3 C++ non empaquetées a été résolu dans Visual Studio 2022 17.2. Si vous utilisez une version antérieure de Visual Studio, mettez à jour Visual Studio vers la version 17.2 pour recevoir ce correctif.

Limitations connues :

  • Dans les projets .NET, les fichiers de ressources copiés-collés dans le dossier du projet ne sont pas indexés sur F5 si l’application a déjà été générée. Pour contourner ce problème, générez à nouveau l’application. Pour plus d’informations, consultez le problème 1503 sur GitHub.

Pour plus d’informations, consultez Gérer les ressources avec MRT Core.

Notifications

Les développeurs d’applications empaquetées (y compris empaquetées avec un emplacement externe) et non empaquetées peuvent désormais envoyer des notifications Windows.

Nouvelles fonctionnalités :

  • Prise en charge des notifications d’application pour les applications empaquetées et non empaquetées.
  • Prise en charge des notifications push pour les applications empaquetées et non empaquetées.

Limitations connues :

  • L’envoi de notifications à partir d’une application avec élévation de privilèges n’est pas pris en charge. PushNotificationManager::IsSupported() n’effectue pas de vérification de mode avec élévation de privilèges.

Fenêtrage

Pour faciliter la programmation de l’accès aux fonctionnalités implémentées dans USER32.dll (voir Fenêtres et messages), cette version présente davantage cette fonctionnalité dans AppWindow directement.

Nouvelles fonctionnalités :

  • Les applications avec des fenêtres existantes ont plus de contrôle sur la façon dont une fenêtre est affichée, en appelant AppWindow.ShowOnceWithRequestedStartupState, l’équivalent de ShowWindow(SW_SHOWDEFAULT).
  • Les applications peuvent afficher, réduire ou restaurer une fenêtre tout en spécifiant si la fenêtre doit être activée ou non au moment où l’appel est effectué.
  • Les applications peuvent désormais déterminer des dimensions spécifiques pour la taille de la zone cliente de leur fenêtre en coordonnées Win32 sans avoir à calculer le dimensionnement de la zone non cliente pour obtenir une taille de zone client spécifique.
  • D’autres API WinRT sont disponibles pour prendre en charge la gestion de l’ordre de plan des fenêtres, sur la base du fonctionnement de hWndInsertAfter de SetWindowPos.
  • Les applications dessinant des barres de titre personnalisées avec AppWindowTitleBar.ExtendsContentIntoTitleBar peuvent définir une option PreferredTitleBarHeight. Vous avez maintenant le choix entre une barre de titre de hauteur standard ou une barre de titre haute qui offre plus d’espace pour le contenu interactif. Consultez Barre de titre dans les instructions de conception Fluent pour obtenir des conseils sur l’utilisation d’une barre de titre haute.

Problèmes résolus :

  • Lorsque le présentateur plein écran est appelé la première fois, la fenêtre s’adapte maintenant à l’ensemble de l’écran correctement. Pour plus d’informations, consultez le problème 1853 sur GitHub.
  • Les fenêtres créées avec AppWindow::GetFromWindowId ont OverlappedPresenter comme présentateur par défaut, mais n’ont pas de restrictions en matière de modifications des styles de fenêtre provenant d’autres API. Les fenêtres créées avec AppWindow::Create auront les garde-fous Presenter par défaut en place dès le début. Pour plus d’informations, consultez le problème 2049 sur GitHub.
  • L’utilisation de l’API OverlappedPresenter.SetBorderAndTitlebar pour masquer les boutons et bordures de légende entraîne une bordure supérieure de 1 px lors de l’agrandissement. Ce problème a été résolu. Pour plus d’informations, consultez le problème 1693 sur GitHub.

Limitations connues :

  • Lorsque vous utilisez l’API AppWindowTitlebar pour personnaliser les couleurs de la barre de titre standard, l’icône et le texte sont mal alignés par rapport à la barre de titre standard. Pour plus d’informations, consultez le problème GitHub 2459.

  • Lors de la résolution du problème GitHub 2049 (vu ci-dessus), nous avons introduit le bogue suivant : si vous appliquez un AppWindowPresenter à une AppWindow que vous avez récupérée à partir de GetFromWindowId, modifiez un style de fenêtre suivi par ce présentateur en appelant les API USER32, puis essayez de revenir à l’état précédent de la fenêtre en appliquant à nouveau le présentateur par défaut, le résultat est une fenêtre qui n’a pas de barre de titre. Si vous vous appuyez sur un présentateur dans votre application et que vous utilisez des appels à USER32 pour modifier les styles de fenêtre au moment où un présentateur autre que celui par défaut est appliqué, vous devrez peut-être ajouter une solution de contournement pour garantir le comportement correct de la fenêtre jusqu’à ce que ce bogue soit résolu. Vous pouvez utiliser l’extrait de code suivant comme modèle pour contourner le problème :

    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

Les composants Windows Runtime C#, y compris les contrôles personnalisés WinUI, sont désormais pris en charge. Cela permet aux auteurs de composants de distribuer des composants de runtime créés en C# à n’importe quel langage compatible WinRT (par exemple C++/WinRT). Consultez Procédure pas à pas : Créer un composant C# avec des contrôles WinUI 3 et le consommer à partir d’une application C++/WinRT qui utilise le SDK d’application Windows et l’exemple sur GitHub pour commencer.

Autres limitations et problèmes connus

  • Les applications qui référencent un package qui dépend de WebView2 (comme Microsoft.Identity.Client) ne parviennent pas à être générées. Cela est dû à des fichiers binaires en conflit au moment de la génération. Pour plus d’informations, consultez le problème 2492 sur GitHub.
  • L’utilisation de dotnet build avec un projet de bibliothèque de classes C# WinAppSDK peut causer une erreur de génération « La tâche Microsoft.Build.Packaging.Pri.Tasks.ExpandPriContent n’a pas pu être chargée ». Pour résoudre ce problème, définissez <EnableMsixTooling>true</EnableMsixTooling> dans votre fichier projet.
  • Les modèles WinAppSDK par défaut notent que maxVersionTested="10.0.19041.0" au lieu de "10.0.22000.0". Pour une prise en charge complète de certaines fonctionnalités, notamment les UnlockedDEH, mettez à jour MaxVersionTested vers « 10.0.22000.0 » dans votre fichier projet.

Version 1.0

La dernière version disponible de la traçabilité 1.0.x du canal stable du SDK d’application Windows est la version 1.0.4. 1.0.x prend en charge toutes les fonctionnalités du canal stable (voir la section Fonctionnalités disponibles par canal de publication des Canaux de publication du SDK d’application Windows).

Version 1.0.4

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.0.

Résolution des bogues

  • Correction d’un problème entraînant l’affichage à l’écran des AppBars, lorsqu’elles sont utilisées en tant que Page.TopAppBar ou Page.BottomAppBar.
  • Résolution du problème où les applications avec un nom de package de 12 caractères ou moins qui utilisent un contrôle WinUI à partir de MUXControls.dll se bloquaient immédiatement. Pour plus d’informations, consultez le problème 6360 sur GitHub.
  • Correction des problèmes d’entrée tactile provoquant des problèmes liés aux raccourcis clavier et à d’autres scénarios. Pour plus d’informations, consultez le problème 6291 sur GitHub.
  • Correction d’un problème entraînant l’échec du déploiement d’applications empaquetées avec MSIX ou autonomes.
  • Correction d’un problème entraînant parfois le blocage des applications lors d’une opération de glisser-déplacer. Pour plus d’informations, consultez le problème 7002 sur GitHub.

Version 1.0.3

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.0.

Résolution des bogues

  • Résolution d’un problème entraînant le blocage des applications C# avec WebView2 au lancement lorsque le runtime C/C++ (CRT) n’était pas installé.
  • Correction des problèmes d’entrée tactile provoquant des problèmes liés aux raccourcis clavier et à d’autres scénarios. Pour plus d’informations, consultez le problème 6291 sur GitHub.

Remarque : En règle générale, nous n’ajoutons pas de fonctionnalités dans une version de maintenance, mais le correctif WebView2 de cette version nous a obligés à effectuer une mise à jour vers la dernière version du SDK WebView2 (1020.46 à 1185.39). Consultez les Notes de publication pour le SDK WebView2 pour plus d’informations sur WebView2 1.0.1185.39 et Distribuer votre application et le runtime WebView2 pour plus d’informations sur le runtime WebView2.

Version 1.0.2

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 1.0.

Résolution des bogues

  • Correction d’un problème de cycle de disposition provoquant le blocage d’une application lors du défilement jusqu’à la fin d’un contrôle ListView. Pour plus d’informations, consultez le problème 6218 sur GitHub.
  • Résolution d’un problème entraînant le blocage des applications C# au lancement lorsque le runtime C/C++ (CRT) n’était pas installé. Toutefois, le CRT est toujours requis pour les applications C# utilisant WebView2. Pour plus d’informations, consultez le problème 2117 sur GitHub.
  • Correction du problème où les applications avec MSIX à projet unique ne généraient pas de fichier .appinstaller. Pour plus d’informations, consultez le problème 1821 sur GitHub.
  • Correction du problème où les applications WinUI ne prenaient pas en charge .NET 6 dotnet build.

Version 1.0.1

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques et une prise en charge multi-fenêtre pour la version 1.0.

Résolution des bogues

  • Correction d’un problème empêchant la compilation de MddBootstrapAutoinitializer avec les ImplicitUsings activés. Pour plus d’informations, consultez le problème 1686 sur GitHub.
  • Correction d’un problème où le focus dans WebView2 était perdu de façon inattendue, provoquant des problèmes d’entrée et de sélection. Pour plus d’informations, consultez les problèmes 5615 et 5570 sur GitHub.
  • Résolution d’un problème empêchant l’utilisation d’une barre d’outils dans l’application dans Visual Studio lors de l’utilisation d’une barre de titre personnalisée dans une application WinUI 3.
  • Résolution d’un problème empêchant l’affichage de la disposition d’alignement lors de l’utilisation d’une barre de titre personnalisée dans une application WinUI 3. Pour plus d’informations, consultez les problèmes 6333 et 6246 sur GitHub.
  • Correction d’un problème provoquant une exception lors de la définition de la propriété Window.ExtendsContentIntoTitleBar lorsque Window.SetTitlebar a été appelé avec un élément UIElement à chargement continu.
  • Correction du problème où les applications MSIX à projet unique ne prenaient pas en charge dotnet build.
  • Correction d’un problème entraînant l’installation d’applications non empaquetées après l’installation d’une application empaquetée. Pour plus d’informations, consultez le problème 1871 sur GitHub.
  • Correction du problème de réduction des performances pendant les opérations de glissement de la souris.
  • Correction du blocage lors de l’appel de GetWindowIdFromWindow() dans les applications non empaquetées. Pour plus d’informations, consultez la discussion 1891 sur GitHub.

Les limitations et problèmes connus pour la version 1.0 s’appliquent également à la version 1.0.1.

De plus, pour les applications avec des barres de titre personnalisées, nous avons apporté des modifications dans cette version (et corrigé de nombreux problèmes) qui incluent des corrections à la fenêtre en verre utilisée pour les opérations de glisser-déposer. Il est recommandé d’utiliser les valeurs et les comportements par défaut (donnez-leur une chance !). Si votre barre de titre utilisait des marges de sorte que les boutons de légende par défaut étaient interactifs, nous vous recommandons de visualiser votre zone de glissement en définissant l’arrière-plan de votre barre de titre sur rouge, puis en ajustant les marges pour étendre la zone de glissement aux contrôles de légende.

Nouvelles fonctionnalités

Nous avons stabilisé et activé la création de plusieurs fenêtres sur le même thread dans les applications WinUI 3. Pour plus d’informations, consultez le problème 5918.

Version 1.0

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour la version 1.0.

WinUI 3

WinUI 3 est le framework d’expérience utilisateur natif pour le SDK d’application Windows. Dans cette version, nous avons ajouté plusieurs nouvelles fonctionnalités du SDK d’application Windows 0.8 et stabilisé des problèmes des versions 1.0 Preview.

Nouvelles fonctionnalités et mises à jour :

  • Nous avons ajouté de nouveaux contrôles (PipsPager, Expander, BreadcrumbBar) et mis à jour les contrôles existants pour refléter les derniers styles Windows de WinUI 2.6.
  • L’empaquetage MSIX à projet unique est pris en charge dans WinUI en créant une application à l’aide de l’option « Application vide, empaquetée... » .
  • Nous prenons désormais en charge le déploiement d’applications WinUI 3 qui ne sont pas empaquetées sur Windows versions 1809 et ultérieures. Pour plus d’informations, consultez Créer votre premier projet WinUI 3.
  • Les projets WinUI 3 peuvent désormais définir leur version cible sur Windows 10, version 1809. Auparavant, ils ne pouvaient être définis qu’à la version 1903.
  • La barre d'outils dans l’application, le Rechargement à chaud et l’arborescence visuelle dynamique pour les applications empaquetées WinUI sont pris en charge dans Visual Studio 2022 Aperçu 5 et GA.

Limitations importantes :

  • Problèmes connus pour les applications WinUI empaquetées et non empaquetées :

    • Erreur d’exécution dans les applications C++ ou C# qui référencent un composant Windows Runtime C++ :

      • Pour résoudre ce problème, ajoutez la cible ci-dessous à la fin du fichier .vcxproj du composant de runtime Windows :

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

      • L’erreur attendue est similaire à l’erreur d’origine WinRT : 0x80004005 : « Impossible de localiser la ressource à partir de ’ms-appx:///BlankPage.xaml’. ».

  • Problèmes connus pour les applications WinUI avec MSIX à projet unique (application vide, modèle empaqueté) :

    • Élément de menu Package & Publish manquant jusqu'à ce que vous redémarriez Visual Studio : Lorsque vous créez une nouvelle app avec MSIX à projet unique à la fois dans Visual Studio 2019 et Visual Studio 2022 à l'aide du modèle de projet App vierge, package (WinUI 3 in Desktop), la commande permettant de publier le projet n'apparaît pas dans le menu tant que vous ne fermez pas et ne rouvrez pas Visual Studio.
    • Une application C# avec MSIX à projet unique ne sera pas compilée sans le composant facultatif « Outils de plateforme Windows universelle C++ (v14x) » installé. Pour plus d’informations, consultez Installer des outils pour le SDK d’application Windows.
    • Erreur d’exécution potentielle dans une application avec MSIX à projet unique qui consomme des types définis dans un composant Windows Runtime référencé : pour résoudre ce problème, ajoutez manuellement des entrées de classe activables à appxmanifest.xml.
      • L’erreur attendue dans les applications C# est « COMException : Classe non inscrite (0x80040154 (REGDB_E_CLASSNOTREG)) ».
      • L’erreur attendue dans les applications C++/WinRT est « winrt::hresult_class_not_registered ».

  • Problèmes connus pour les applications WinUI 3 qui ne sont pas empaquetées (applications non empaquetées) :

  • Problèmes connus liés à l’empaquetage et au déploiement d’applications WinUI :

    • La commande Package n’est pas prise en charge dans les applications WinUI avec MSIX à projet unique (application vide, modèle empaqueté). Utilisez plutôt la commande Package & Publish pour créer un package MSIX.
    • Pour créer un package NuGet à partir d’une bibliothèque de classes C# avec la commande Pack, vérifiez que la Configuration active est Release.
    • La commande Pack n’est pas prise en charge dans les composants de runtime Windows C++ pour créer un package NuGet.

Pour plus d’informations ou pour commencer à développer avec WinUI, consultez :

Fenêtrage

le SDK d’application Windows fournit une classe AppWindow qui fait évoluer la classe en préversion Windows.UI.WindowManagement.AppWindow précédente facile à utiliser et la rend disponible pour toutes les applications Windows, y compris Win32, WPF et WinForms.

Nouvelles fonctionnalités

  • AppWindow est une API de fenêtrage de haut niveau qui permet des scénarios de fenêtrage faciles à utiliser qui s’intègrent bien à l’expérience utilisateur Windows et à d’autres applications. Représente une abstraction générale d’un conteneur géré par le système du contenu d’une application. Il s’agit du conteneur dans lequel votre contenu est hébergé et représente l’entité avec laquelle les utilisateurs interagissent quand ils redimensionnent et déplacent votre application à l’écran. Pour les développeurs familiarisés avec Win32, AppWindow peut être considéré comme une abstraction de haut niveau du HWND.
  • DisplayArea représente une abstraction de haut niveau d’un HMONITOR, et suit les mêmes principes qu’AppWindow.
  • DisplayAreaWatcher permet à un développeur d’observer les modifications apportées à la topologie d’affichage et d’énumérer les DisplayAreas actuellement définies dans le système.

Pour plus d’informations, consultez Gérer les fenêtres d’application.

Entrée

Il s’agit des API d’entrée qui prennent en charge WinUI et fournissent une surface d’API de niveau inférieur pour permettre aux développeurs d’obtenir des interactions d’entrée plus avancées.

Nouvelles fonctionnalités

  • API de pointeur : PointerPoint, PointerPointProperties et PointerEventArgs pour prendre en charge la récupération des informations d’événement de pointeur avec les API d’entrée XAML.
  • API InputPointerSource : représente un objet inscrit pour l’entrée du pointeur de rapport et fournit la gestion des événements de curseur de pointeur et d’entrée pour l’API SwapChainPanel de XAML.
  • API Cursor : permet aux développeurs de modifier l’image bitmap du curseur.
  • API GestureRecognizer : permet aux développeurs de reconnaître certains gestes comme le glissement, l’appui prolongé et le clic lorsque des informations de pointeur sont données.

Limitations importantes

  • Toutes les fonctions de fabrique statique de PointerPoint ont été supprimées : GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints et GetIntermediatePointsTransformed.
  • Le SDK d’application Windows ne prend pas en charge la récupération d’objets PointerPoint avec des ID de pointeur. Au lieu de cela, vous pouvez utiliser la fonction membre GetTransformedPoint de PointerPoint pour récupérer une version transformée d’un objet PointerPoint existant. Pour les points intermédiaires, vous pouvez utiliser les fonctions membres de GetIntermediatePoints et GetTransformedIntermediatePoints de PointerEventArgs.
  • L’utilisation directe de l’API de SDK de plateforme Windows.UI.Core.CoreDragOperation ne fonctionnera pas avec les applications WinUI.
  • Les propriétés RawPosition et ContactRectRaw de PointerPoint ont été supprimées, car elles faisaient référence à des valeurs non prédites, qui étaient identiques aux valeurs normales dans le système d’exploitation. Utilisez Position et ContactRect à la place. La prédiction de pointeur est désormais gérée avec l’objet d’API Microsoft.UI.Input.PointerPredictor.

Cycle de vie d’application

La plupart des fonctionnalités de cycle de vie des applications existent déjà dans la plateforme UWP et ont été introduites dans le SDK d’application Windows pour être utilisées par les types d’applications de bureau, en particulier les applications console non empaquetées, les applications Win32, les applications Windows Forms et les applications WPF. L’implémentation du SDK d’application Windows de ces fonctionnalités ne peut pas être utilisée dans les applications UWP, car il existe des fonctionnalités équivalentes dans la plateforme UWP elle-même.

Important

Si vous utilisez une application UWP, consultez Migrer d’UWP vers le SDK d’application Windows.

Les applications non UWP peuvent également être empaquetées dans des packages MSIX. Bien que ces applications puissent utiliser certaines des fonctionnalités de cycle de vie des applications du SDK d’application Windows, elles doivent utiliser l’approche de manifeste lorsqu’elles sont disponibles. Par exemple, elles ne peuvent pas utiliser les API RegisterForXXXActivation du SDK d’application Windows et doivent à la place s’inscrire pour une activation enrichie via le manifeste.

Toutes les contraintes pour les applications empaquetées s’appliquent également aux applications WinUI, qui sont empaquetées, et il existe des considérations supplémentaires, comme décrit ci-dessous.

Considérations importantes :

  • Activation enrichie : GetActivatedEventArgs

  • Inscrire/annuler l’inscription de l’activation enrichie

    • Applications non empaquetées : entièrement utilisables.
    • Applications empaquetées : non utilisables, utilisez le manifeste MSIX de l’application à la place.
    • Pour plus d’informations, consultez Activation enrichie.

  • Instanciation unique/multi-instanciation

    • Applications non empaquetées : entièrement utilisables.
    • Applications empaquetées : entièrement utilisables.
    • Applications WinUI : si une application souhaite détecter d’autres instances et rediriger une activation, elle doit le faire le plus tôt possible, avant d’initialiser des fenêtres, etc. Pour cela, l’application doit définir DISABLE_XAML_GENERATED_MAIN et écrire un Main (C#) ou WinMain (C++) personnalisé où elle peut effectuer la détection et la redirection.
    • RedirectActivationToAsync est un appel asynchrone et vous ne devez pas attendre un appel asynchrone si votre application s’exécute dans une STA. Pour les applications Windows Forms et WinUI C#, vous pouvez déclarer Main comme étant asynchrone, si nécessaire. Pour les applications WinUI C++ et WPF C#, vous ne pouvez pas déclarer Main comme étant asynchrone ; vous devez déplacer l’appel de redirection vers un autre thread pour vous assurer de ne pas bloquer la STA.
    • Pour plus d’informations, voir Instanciation d’application.

  • Notifications d’alimentation/état

    • Applications non empaquetées : entièrement utilisables.
    • Applications empaquetées : entièrement utilisables.
    • Pour plus d’informations, consultez Gestion de l’alimentation.

Problème connu :

  • Les associations de type de fichier encodent incorrectement %1 en %251 lors de la définition du modèle de ligne de commande du gestionnaire Verb, qui bloque les applications Win32 non empaquetées. Vous pouvez modifier manuellement la valeur du Registre pour qu’elle soit %1 à la place, comme solution de contournement partielle. Si le chemin du fichier cible contient une espace, la commande échoue toujours et il n’existe aucune solution de contournement pour ce scénario.
  • Ces bogues d’instanciation unique/multi-instanciation seront résolus dans un correctif de maintenance à venir :
    • La redirection AppInstance ne fonctionne pas lorsqu’elle est compilée pour x86
    • L’inscription d’une clé, sa désinscription et sa réinscription entraînent le blocage de l’application

DWriteCore

DWriteCore est l’implémentation du SDK d’application Windows de DirectWrite, qui est l’API DirectX pour le rendu de texte de haute qualité, les polices de plan indépendantes de la résolution et la prise en charge de la disposition et du texte Unicode intégral. DWriteCore est une forme de DirectWrite qui s’exécute sur les versions de Windows jusqu’à Windows 10, version 1809 (10.0 ; Build 17763), et qui vous permet de l’utiliser sur plusieurs plateformes.

Fonctionnalités DWriteCore contient toutes les fonctionnalités de DirectWrite, à quelques exceptions près.

Limitations importantes

  • DWriteCore ne contient pas les fonctionnalités DirectWrite suivantes :
    • Polices par session
    • Polices de caractères définies par l’utilisateur final (EUDC)
    • API de diffusion en continu de polices
  • La prise en charge de l’API de rendu de bas niveau est partielle.
  • DWriteCore n’interagit pas avec Direct2D, mais vous pouvez utiliser IDWriteGlyphRunAnalysis et IDWriteBitmapRenderTarget.

Pour plus d’informations, consultez Vue d’ensemble de DWriteCore.

MRT Core

MRT Core est une version simplifiée du système de gestion des ressources Windows moderne qui est distribué dans le cadre du SDK d’application Windows.

Limitations importantes

  • Dans les projets .NET, les fichiers de ressources copiés-collés dans le dossier du projet ne sont pas indexés sur F5 si l’application a déjà été générée. Pour contourner ce problème, générez à nouveau l’application. Pour plus d’informations, consultez le problème 1503.
  • Dans les projets .NET, lorsqu’un fichier de ressources est ajouté au projet à l’aide de l’interface utilisateur de Visual Studio, les fichiers peuvent ne pas être indexés par défaut. Pour plus d’informations, consultez le problème 1786. Pour contourner ce problème, supprimez les entrées ci-dessous dans le fichier CSPROJ : 
    <ItemGroup>
    <Content Remove="<image file name>" />
</ItemGroup>
<ItemGroup>
    <PRIResource Remove="<resw file name>" />
</ItemGroup>
  • Pour les applications WinUI C++ non empaquetées, l’URI de ressource n’est pas généré correctement. Pour contourner ce problème, ajoutez ce qui suit dans le vcxproj : 
    <!-- Add the following after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> -->

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

Pour plus d’informations, consultez Gérer les ressources avec MRT Core.

Déploiement

Nouvelles fonctionnalités et mises à jour

Limitations importantes

  • Le wrapper .NET pour l’API Bootstrapper est uniquement destiné à être utilisé par les applications .NET non empaquetées afin de simplifier l’accès aux SDK d’application Windows.
  • Seules les applications empaquetées MSIX qui sont entièrement approuvées ou dont la fonctionnalité packageManagement est restreinte ont l’autorisation d’utiliser l’API de déploiement pour installer les dépendances de package main et singleton. La prise en charge des applications empaquetées à confiance partielle sera disponible dans les versions ultérieures.
  • Lorsque F5 teste une application x86 qui utilise la méthode DeploymentManager.Initialize sur un système x64, vérifiez que le framework x64 est installé d’abord en exécutant WindowsAppRuntimeInstall.exe. Sinon, vous rencontrerez une erreur NOT_FOUND en raison du fait que Visual Studio ne déploie pas le framework x64, ce qui se produit normalement par le biais du déploiement via le Store ou du chargement indépendant.

Autres limitations et problèmes connus

  • Aucune prise en charge de configuration de build de processeur : lorsque vous ajoutez le SDK d’application Windows à une application ou un composant .NET existant qui prend en charge n’importe quel processeur, vous devez spécifier l’architecture souhaitée : x86, x64 ou arm64.

  • Mise à niveau de .NET 5 vers .NET 6 : lors de la mise à niveau dans l’interface utilisateur de Visual Studio, vous risquez de créer des erreurs de build. Pour contourner ce problème, mettez à jour manuellement le fichier TargetFrameworkPackagede votre projet avec les éléments ci-dessous :

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

  • L’application MSIX à projet unique C# ne compile pas si les outils UWP C++ ne sont pas installés. Si vous avez un projet MSIX à projet unique C#, vous devez installer le composant facultatif Outils de plateforme Windows universelle C++ (v14x).

  • Le VSIX de langage suivant ne parvient pas à s’installer dans Visual Studio 2019 lorsque plusieurs versions de Visual Studio 2019 sont installées. Si plusieurs versions de Visual Studio 2019 sont installées (par exemple, Version et Préversion), puis que vous installez le VSIX du SDK d’application Windows pour C++ et C#, la deuxième installation échoue. Pour résoudre ce problème, désinstallez les outils d’empaquetage MSIX à projet unique pour Visual Studio 2019 après le premier VSIX de langage. Consultez ces retours pour plus d’informations sur ce problème.

  • Une alternative à DispatcherQueue.TryEnqueue (pour reprendre l’exécution sur le thread de file d’attente du répartiteur) consiste à utiliser la fonction d’assistance resume_foreground dans la bibliothèque d’implémentation Windows (WIL) :

    1. Ajoutez une référence à votre projet au package NuGet Microsoft.Windows.ImplementationLibrary .
    2. Ajoutez #include <wil/cppwinrt_helpers.h> à votre pch.h.
    3. Ajoutez #include <winrt/Microsoft.UI.Dispatching.h> à votre pch.h.
    4. Maintenant co_await wil::resume_foreground(your_dispatcherqueue);.

Version 0.8

La dernière version disponible de la traçabilité 0.8.x du canal stable du SDK d’application Windows est la version 0.8.12.

Notes

Le kit SDK Windows App était connu sous le nom de code Project Reunion. Certaines ressources du SDK dans les versions 0.8 et antérieures utilisent toujours le nom de code. Certaines parties de la documentation utilisent toujours Project Reunion quand elles font référence à un composant existant ou à une version antérieure spécifique.

Version 0.8.12

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 0.8.0.

Notes

Pour les développeurs C#, l’une des versions suivantes du SDK .NET est requise : 5.0.213, 5.0.407, 6.0.104, 6.0.202 (ou version ultérieure). Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio. Sans la version requise du SDK .NET, lors de la mise à jour de votre package NuGet, vous verrez une erreur du type : « Cette version de WindowsAppSDK nécessite WinRT.Runtime.dll version 1.6 ou ultérieure ».

Correctifs de bogues :

  • Résolution d’un problème où les applications avec SwapChainPanel ou WebView2 se bloquaient de façon imprévisible en raison d’une violation d’accès.

Version 0.8.11

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 0.8.0.

Notes

Pour les développeurs C#, l’une des versions suivantes du SDK .NET est requise : 5.0.213, 5.0.407, 6.0.104, 6.0.202 (ou version ultérieure). Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio. Sans la version requise du SDK .NET, lors de la mise à jour de votre package NuGet, vous verrez une erreur du type : « Cette version de WindowsAppSDK nécessite WinRT.Runtime.dll version 1.6 ou ultérieure ».

Correctifs de bogues :

  • Correction de la régression provoquant le déclenchement de l’événement de focus perdu lors de la sélection de texte à l’aide de la souris.

Version 0.8.10

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 0.8.0.

Notes

Pour les développeurs C#, l’une des versions suivantes du SDK .NET est requise : 5.0.213, 5.0.407, 6.0.104, 6.0.202 (ou version ultérieure). Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio. Sans la version requise du SDK .NET, lors de la mise à jour de votre package NuGet, vous verrez une erreur du type : « Cette version de WindowsAppSDK nécessite WinRT.Runtime.dll version 1.6 ou ultérieure ».

Correctifs de bogues :

  • Correction de problèmes entraînant parfois le blocage des applications lors d’une opération de glisser-déplacer.

Notes

Le SDK d’application Windows 0.8.9 n’a pas été publié. La version publiée directement après la version 0.8.8 est 0.8.10.

Version 0.8.8

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut des correctifs de bogues critiques pour la version 0.8.0.

Notes

Pour les développeurs C#, l’une des versions suivantes du SDK .NET est requise : 6.0.202, 6.0.104, 5.0.407, 5.0.213 (ou version ultérieure). Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio. Sans la version requise du SDK .NET, lors de la mise à jour de votre package NuGet, vous verrez une erreur du type : « Cette version de WindowsAppSDK nécessite WinRT.Runtime.dll version 1.6 ou ultérieure ».

Correctifs de bogues :

  • Correction des problèmes d’entrée tactile dans TextBox concernant le clavier logiciel et l’interaction générale. Ces problèmes affectaient également les raccourcis clavier. Pour plus d’informations, consultez le problème 6291 sur GitHub.
  • Correction d’un problème où une fenêtre d’application s’affichait parfois comme inactive alors qu’elle était active.
  • Correction d’un problème de performances provoqué par l’exécution d’UIA (UI Automation) dans des processus externes.
  • Correction du problème de stabilité de l’application avec l’entrée du stylet.
  • Résolution d’un problème où le rendu des icônes png dans un menu était considérablement retardé en raison d’UIA.

Version 0.8.7

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut plusieurs mises à jour de performances pour les applications C#/.NET. Pour effectuer une mise à jour vers cette version, vous devez référencer la dernière version du package du SDK Windows. Pour ce faire, ajoutez la propriété <WindowsSdkPackageVersion>10.0.<sdk_version>.24</WindowsSdkPackageVersion> à votre fichier .csproj avec la version du SDK que votre application cible à partir de la propriété TargetFramework. Exemple :

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

Cette version de projection du SDK Windows sera disponible dans une prochaine version de maintenance de .NET 6. Une fois la mise à jour du SDK .NET disponible, vous devez supprimer la propriété <WindowsSdkPackageVersion> de votre fichier projet.

Si vous ne définissez pas cette propriété, vous verrez une erreur comme : "Error: This version of Project Reunion requires WinRT.Runtime.dll version 1.6 or greater."

Version 0.8.6

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut plusieurs améliorations des performances pour les applications C#/.NET pour la version 0.8.0.

Pour effectuer une mise à jour vers cette version du SDK d’application Windows, vous devez avoir installé la dernière mise à jour de décembre du SDK .NET (voir Télécharger .NET et .NET 5 atteindra la fin du support le 10 mai 2022). Si vous n’avez pas la version minimale requise du SDK .NET installée, vous verrez une erreur comme "Error: This version of Project Reunion requires WinRT.Runtime.dll version 1.4 or greater."

Correctifs de bogues

Pour obtenir une liste détaillée des améliorations apportées aux performances, consultez les notes de publication de C#/WinRT 1.4.1.

Version 0.8.5

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut d’autres correctifs de bogues critiques pour la version 0.8.0.

Résolution des bogues

  • Résolution du problème qui provoquait le blocage des applications WinUI utilisant l’entrée de pointeur.
  • Correction d’un problème qui empêchait les boutons de la barre de titre (min, max, close) d’avoir des coins arrondis sur Windows 11.
  • Résolution d’un problème empêchant l’affichage des options de disposition de redimensionnement lors du pointage sur le bouton Agrandir/Restaurer sur Windows 11.
  • Correction d’un problème provoquant une exception de blocage lors de la création d’un objet PointCollection. Pour plus d’informations, consultez le problème 971 sur GitHub.

Les limitations et les problèmes connus pour la version 0.8 s’appliquent également à la version 0.8.5, sauf indication contraire dans la section ci-dessous.

Version 0.8.4

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut d’autres correctifs de bogues critiques pour la version 0.8.0.

Résolution des bogues

  • Corrige les barres de titre personnalisées afin que ContentDialog ne les couvre pas et que les boutons de la barre de titre soient arrondis.
  • Correction d’un blocage dans le traitement des images lorsque l’échelle d’affichage est modifiée.
  • Corrige les bogues de découpage où l’interface utilisateur disparaît ou se coupe incorrectement

Les limitations et les problèmes connus pour la version 0.8 s’appliquent également à la version 0.8.4, sauf indication contraire dans la section ci-dessous.

Version 0.8.3

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut d’autres correctifs de bogues critiques pour la version 0.8.0.

Résolution des bogues

Le focus clavier était perdu lorsqu’une fenêtre était réduite, puis restaurée, nécessitant un clic de souris pour restaurer le focus.

Les limitations et les problèmes connus pour la version 0.8 s’appliquent également à la version 0.8.3, sauf indication contraire dans la section ci-dessous.

Version 0.8.2

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut d’autres correctifs de bogues critiques pour la version 0.8.0.

Résolution des bogues

  • Le SDK d’application Windows et WinUI 3 sont désormais pris en charge dans Visual Studio 2022 Preview 2 et versions ultérieures.
  • Pour les applications .NET, vous pouvez recevoir l’erreur suivante lors du passage d’un tableau d’énumérations : Object contains non-primitive or non-blittable data.
  • L’écriture à l’aide du panneau d’écriture manuscrite à l’intérieur d’une zone de texte provoque un blocage
  • Les icônes/images se chargent toujours à leur valeur d’échelle de 100 % plutôt qu’en fonction de la valeur d’échelle du moniteur
  • Le nettoyage de mémoire d’EventSource<T> entraîne l’échec ultérieur de la désinscription des gestionnaires (consultez ce problème GitHub pour plus d’informations)
  • Correctif de sécurité : pour plus d’informations, consultez CVE-2021-34533.
  • SwapChainPanel.CompositionScaleChanged retourne parfois des valeurs CompositionScale incorrectes après modification de l’échelle d’affichage

Les limitations et les problèmes connus pour la version 0.8 s’appliquent également à la version 0.8.2, sauf indication contraire dans la section ci-dessous.

Version 0.8.1

Il s’agit d’une version de maintenance du SDK d’application Windows qui inclut quelques correctifs de bogues critiques pour la version 0.8.0.

Résolution des bogues

  • Le SDK d’application Windows ne peut pas s’exécuter sur la dernière version de Windows Insider
  • Blocage dans EditableComboBox lors de l’entrée d’une valeur qui n’apparaît pas dans la liste déroulante
  • WebView2 ne permet pas à l’utilisateur d’utiliser la tabulation une fois que le focus a été reçu
  • Qualifier entièrement l’espace de noms Windows.Foundation.Metadata.DefaultOverload dans le code généré WinUI pour éviter toute ambiguïté de l’espace de noms
    • Cela corrige le bogue #5108.
  • Correctif de sécurité : consultez CVE-2021-34489 pour plus d’informations.

Les limitations et les problèmes connus pour la version 0.8 s’appliquent également à la version 0.8.1, sauf indication contraire dans la section ci-dessous.

Version 0.8.0 stable

Nouvelles fonctionnalités et mises à jour

Cette version prend en charge toutes les fonctionnalités du canal stable.

WinUI 3

Cette version inclut de nombreux correctifs de bogues et une stabilisation améliorée dans WinUI 3. Voici toutes les nouvelles modifications apportées à WinUI 3 depuis la publication de WinUI 3 - Project Reunion 0.5 :

  • Le contrôle Pivot a été rajouté et peut désormais être utilisé dans n’importe quelle application WinUI 3.

  • Tous les correctifs de bogues de Project Reunion v0.5.5, v0.5.6 et v0.5.7 sont inclus dans cette version.

  • Nouveaux correctifs de bogues, notamment :

    • Cliquer avec le bouton droit dans TextBox fait planter l’application
    • NavigationView provoque un plantage dans Project Reunion 0.5 Preview dans la plateforme UWP
    • La barre de progression ne montre pas la différence entre l’option Mise en pause et Erreur
    • Blocage dans RichEditBox lors de la copie/du collage/de la modification du style de texte
    • Les boutons de légende d’une fenêtre sont mal placés quand SetTitleBar n’est pas défini ou a la valeur null

    Pour obtenir la liste complète des bogues résolus dans cette version, consultez notre référentiel GitHub.

  • L’API ColorHelper.ToDisplayName n’est plus disponible.

  • Les types suivants ont été supprimés :

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

    Utilisez plutôt Windows.Graphics.IGeometrySource2D et Windows.Graphics.IGeometrySource2DInterop.

  • Tous les types de l’espace de noms Microsoft.System ont été déplacés vers l’espace de noms Microsoft.UI.Dispatching, y compris la classe DispatcherQueue.

  • La propriété AcrylicBrush.BackgroundSource a été supprimée, car HostBackdrop n’est pas pris en charge en tant que BackgroundSource dans WinUI 3.

Pour plus d’informations sur WinUI, consultez Bibliothèque Windows UI 3 (WinUI).

Pour profiter des contrôles et fonctionnalités WinUI 3, vous pouvez cloner et générer l’application de galerie WinUI 3 à partir de GitHub, ou la télécharger à partir de Microsoft Store.

Pour commencer à développer avec WinUI, consultez les articles suivants :

DWriteCore

Cette version de DWriteCore inclut les fonctionnalités nouvelles et mises à jour suivantes. DWriteCore est présenté et décrit dans la Vue d’ensemble de DWriteCore.

Notes

DWriteCoreCreateFactory est fonctionnellement identique à la fonction DWriteCreateFactory exportée par la version système de DirectWrite. La fonction DWriteCore a un nom différent pour éviter toute ambiguïté dans le cas où vous liez à la fois DWriteCore.lib et DWrite.lib.

Pour obtenir des informations de référence sur les API DWriteCore et DirectWrite, consultez Informations de référence sur l’API DWriteCore et Informations de référence sur l’API DirectWrite.

MRTCore

  • L’action Générer pour les ressources est automatiquement définie lorsque vous ajoutez la ressource à votre projet, ce qui réduit la nécessité d’une configuration manuelle du projet.

Limitations

  • Cette version n’est actuellement pas prise en charge sur le canal de développement du Programme Windows Insider. Ce problème est résolu dans la version 0.8.1.

  • Applications de bureau (C# ou C++ de bureau) : cette version est prise en charge uniquement pour une utilisation dans les applications de bureau (C++ ou C#) qui sont empaquetées à l’aide de MSIX. Pour utiliser le SDK d’application Windows dans les applications de bureau non empaquetées, vous devez utiliser le canal de version expérimentale.

Important

Si vous utilisez une application UWP, consultez Migrer d’UWP vers le SDK d’application Windows.

Problèmes connus

  • Les outils WinUI 3, comme l’arborescence d’éléments visuels en temps réel, l’explorateur de propriétés en temps réel et le rechargement à chaud dans les versions 0.8 et ultérieures nécessitent Visual Studio 2019 16.11 Preview 3 et versions ultérieures.

  • Les applications qui utilisent actuellement WinUI 3 et le SDK d’application Windows 0.8 ne peuvent pas utiliser les bibliothèques de classes qui utilisent Project Reunion 0.5. Mettez à jour les bibliothèques de classes pour utiliser le SDK d’application Windows 0.8.

  • Les applications .NET doivent cibler la build 18362 ou ultérieure : votre TFM doit être défini sur net6.0-windows10.0.18362 ou version ultérieure, et votre projet d’empaquetage doit être défini sur 18362 ou version ultérieure. Pour plus d’informations, consultez le problème GitHub 921.

  • Vous pouvez rencontrer un blocage lorsque vous basculez fréquemment entre le mode clair et le mode sombre.

  • Pour les applications .NET, vous pouvez recevoir l’erreur suivante lors du passage d’un tableau d’énumérations : Object contains non-primitive or non-blittable data.Ce problème est résolu dans la version 0.8.2.

  • Pour les applications .NET, il n’existe actuellement aucun moyen de refuser l’indexation d’une image en tant que ressource d’application à l’aide de l’interface utilisateur de Visual Studio. Pour contourner ce problème, ajoutez un objet Directory.Build.targets (voir Personnaliser votre build - Visual Studio pour obtenir des instructions) au projet et supprimez la ou les images comme suit :

    • Pour supprimer des images spécifiques (notez que le chemin relatif est nécessaire) :

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

    • Pour supprimer des images basées sur des métadonnées :

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

    Un correctif de ce problème est prévu pour une prochaine version . À ce stade, les solutions de contournement ci-dessus ne seront plus nécessaires.

Version 0.5

La dernière version disponible de la traçabilité 0.5.x du canal stable du SDK d’application Windows est la version 0.5.9.

Télécharger

Nouvelles fonctionnalités et mises à jour

Cette version prend en charge toutes les fonctionnalités du canal stable.

Problèmes connus et limitations

Cette version possède les limitations et problèmes connus suivants :

  • Applications de bureau (C# ou C++ de bureau) : cette version est prise en charge uniquement pour une utilisation dans les applications de bureau (C++ ou C#) qui sont empaquetées à l’aide de MSIX. Pour utiliser le SDK d’application Windows dans les applications de bureau non empaquetées, vous devez utiliser le canal de version expérimentale.
  • Les applications .NET doivent cibler la build 18362 ou ultérieure : votre TFM doit être défini sur net6.0-windows10.0.18362 ou version ultérieure, et la <TargetPlatformVersion> de votre projet d’empaquetage doit être défini sur 18362 ou version ultérieure. Pour plus d’informations, consultez ce problème connu sur GitHub.

Important

Si vous utilisez une application UWP, consultez Migrer d’UWP vers le SDK d’application Windows.