Partage via

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

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

Correctifs de bogues (1.0.4)

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

Correctifs de bogues (1.0.3)

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

Correctifs de bogues (1.0.2)

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

Correctifs de bogues (1.0.1)

  • 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.
  • Le package MSIX pour un seul projet est pris en charge dans WinUI en créant une nouvelle application à l'aide du modèle « 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 (SDK d'application Windows).
  • 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, voir Gérer les fenêtres d'application (SDK d'application Windows).

Input

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, voir Rich activation with the app lifecycle API.

  • 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, consultez Instancier des applications avec l’API de cycle de vie de l’application.

  • Notifications d’alimentation/état

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