Partage via

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

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

Liens importants :

Dernière version de la chaîne stable :

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

Remarque

Les extensions SDK d'application Windows 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.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.

nouvelles fonctionnalités, mises à jour et problèmes connus pour la version 1.2

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

Remarque

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.

Changement cassant :

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.