Partage via

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

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

Correctifs de bogues (1.1.5)

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

Correctifs de bogues (1.1.4)

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

Correctifs de bogues (1.1.3)

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

Correctifs de bogues (1.1.2)

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

Correctifs de bogues (1.1.1)

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

Nouvelles fonctionnalités, mises à jour et problèmes connus pour la 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.