Après plusieurs Versions préliminaires, Microsoft vient de publier Windows App SDK 1.0.0 Stable, une boîte à outils qui permet aux développeurs d’applications de bureau de créer des applications avec une interface utilisateur Windows moderne, des API et des fonctionnalités de plate-forme.
Dans cette version, Microsoft a ajouté plusieurs nouvelles fonctionnalités de Windows App SDK 0.8 et problèmes stabilisés des versions 1.0 Preview.
WinUI 3
WinUI 3 est le framework d’expérience utilisateur (UX) natif pour Windows App SDK.
Nouvelles fonctionnalités et mises à jour :
Microsoft a 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.Single-l’emballage du projet MSIX est supp orté dans WinUI en créant une nouvelle application à l’aide du modèle « Application vierge, emballée… ». Microsoft prend désormais en charge le déploiement d’applications WinUI 3 sans package MSIX sur les versions Windows 1809 et supérieures. Veuillez consulter Créer un WinUI 3 non compressé application de bureau pour plus d’informations. 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’à partir de la version 1903. Barre d’outils intégrée à l’application, rechargement à chaud et en direct Les applications packagées Visual Tree pour WinUI sont prises en charge dans Visual Studio 2022 Preview 5 et GA.
Limites importantes :
Problèmes connus pour les applications WinUI packagées et non packagées : Problèmes connus pour les applications WinUI avec un seul projet MSIX (Application vierge, modèle packagé) : Paquet et élément de menu de publication manquants jusqu’à ce que vous redémarriez Visual Studio : Lors de la création d’une nouvelle application avec un seul projet MSIX dans les deux Visual Studio 2019 et Visual Studio 2022 utilisant le modèle de projet Blank App, Packaged (WinUI 3 in Desktop), la commande pour publier le projet n’apparaît pas dans le moi nu jusqu’à ce que vous fermiez et rouvrez Visual Studio. Une application C# avec un seul projet MSIX ne sera pas compilée sans le composant facultatif”C++ (v14x) Universal Windows Platform Tools”installé. Afficher Installer les outils de développement pour plus d’informations. Erreur d’exécution potentielle dans une application avec un projet unique MSIX qui consomme des types définis dans un composant Windows Runtime référencé : Pour résoudre, ajoutez manuellement entrées de classe activables dans le fichier appxmanifest.xml. L’erreur dans les applications C# est « COMException : classe non enregistrée (0x80040154 (REGDB_E_CLASSNOTREG)). (applications non packagées) : certaines API nécessitent l’identité du package et ne sont pas prises en charge dans les applications non packagées, telles que : Problèmes connus pour l’empaquetage et le déploiement d’applications WinUI : le package La commande n’est pas prise en charge dans les applications WinUI avec un seul projet MSIX (application vierge, modèle packagé). À la place, utilisez 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, assurez-vous que la configuration active est Release. La commande Pack n’est pas prise en charge dans C++ Windows Runtime Components pour créer un Package NuGet.
Fenêtrement
Le SDK de l’application Windows fournit un AppWindow classe qui fait évoluer la classe d’aperçu Windows.UI.WindowManagement.AppWindow précédente et 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 avec l’utilisateur Windows expérience et avec d’autres applications. Représente une abstraction de haut niveau 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 lorsqu’ils redimensionnent et déplacent votre application à l’écran. Pour les développeurs familiers 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, suit les mêmes principes qu’AppWindow.DisplayAreaWatcher permet à un développeur d’observer les changements dans la topologie d’affichage et d’énumérer DisplayAreas actuellement définies dans le système.
Input
Ce sont les API d’entrée qui prennent en charge WinUI et fournissent une surface d’API de niveau inférieur pour que les développeurs réalisent des interactions d’entrée plus avancées.
Nouvelles fonctionnalités
Limites importantes
Toutes PointerPoint les fonctions d’usine statiques ont été supprimées : GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints et GetIntermediatePointsTransformed. ne prend pas en charge la récupération d’objets PointerPoint avec des identifiants de pointeur. À la place, vous pouvez utiliser la fonction membre PointerPoint GetTransformedPoint pour récupérer une version transformée d’un objet PointerPoint existant. Pour les points intermédiaires, vous pouvez utiliser les fonctions membres PointerEventArgs GetIntermediatePoints et GetTransformedIntermediatePoints. Utilisation directe de l’API SDK de la plate-forme Windows.UI.Core.CoreDragOperation ne fonctionnera pas avec les applications WinUI.PointerPoint les propriétés RawPosition et ContactRectRaw ont été supprimées car elles faisaient référence à des valeurs non prévues, qui étaient les mêmes que les valeurs normales dans le système d’exploitation. Utiliser Position et ContactRect à la place. La prédiction de pointeur est désormais gérée avec l’objet API Microsoft.UI.Input.PointerPredictor.
Cycle de vie de l’application
La plupart des fonctionnalités du cycle de vie de l’application existent déjà sur la plate-forme UWP, et ont été introduits dans le SDK de l’application Windows pour être utilisés par les types d’applications de bureau, en particulier les applications de console non compressées, les applications Win32, les applications Windows Forms et les applications WPF. L’implémentation du SDK de l’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 plate-forme UWP elle-même.
Important
Si vous travaillez sur une application UWP, reportez-vous à les conseils de migration UWP pour en savoir plus sur la migration de votre application vers le SDK de l’application Windows.
Les applications non UWP peuvent également être emballé dans des packages MSIX. Bien que ces applications puissent utiliser certaines des fonctionnalités du cycle de vie des applications du kit de développement logiciel Windows, elles doivent utiliser l’approche manifeste lorsque celle-ci est disponible. Par exemple, ils ne peuvent pas utiliser les API Windows App SDK RegisterForXXXActivation et doivent à la place s’inscrire pour une activation enrichie via le manifeste.
Toutes les contraintes pour les applications packagées s’appliquent également aux applications WinUI, qui sont emballés, et il y a des considérations supplémentaires comme décrit ci-dessous.
Considérations importantes :
Activation riche : GetActivatedEventArgsRegister/Unregister for rich activationUnpackaged apps : entièrement utilisable.Packaged applications : non utilisables, utilisez plutôt le manifeste MSIX de l’application. Pour plus d’informations, consultez Activation riche.Applications uniques/multi-instances : entièrement utilisables.Applications packagées : Entièrement utilisables.Applications WinUI : si une application souhaite détecter d’autres instanc es et rediriger une activation, elle doit le faire le plus tôt possible, et avant d’initialiser toute fenêtre, etc. Pour activer cela, l’application doit définir DISABLE_XAML_GENERATED_MAIN et écrire un Main (C#) ou WinMain (C++) personnalisé où elle peut le faire 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 un STA. Pour les applications Windows Forms et C# WinUI, vous pouvez déclarer Main asynchrone, si nécessaire. Pour les applications C++ WinUI et C# WPF, vous ne pouvez pas déclarer Main comme asynchrone. Vous devez donc déplacer l’appel de redirection vers un autre thread pour vous assurer de ne pas bloquer le STA. Pour plus d’informations, consultez Instanciation d’application.Alimentation/notifications d’étatApplications déballées : entièrement utilisables. Applications packagées : entièrement utilisables. Pour plus d’informations, consultez Gestion de l’alimentation.
Problème connu :
Les associations de types de fichiers encodent de manière incorrecte %1 pour être %251 lors de la définition du modèle de ligne de commande du gestionnaire de verbes, ce qui fait planter Win32 décompacté applications. 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 un espace, il échouera toujours et il n’y a pas de solution de contournement pour ce scénario. Ces bogues à instance unique/multi-instance seront corrigés dans un correctif de service à venir : x86L’enregistrement d’une clé, sa désenregistrement et son réenregistrement provoquent le blocage de l’application
DWriteCore
DWriteCore est l’implémentation du SDK de l’application Windows de DirectWrite, qui est l’API DirectX pour un rendu de texte de haute qualité, des polices vectorielles indépendantes de la résolution et Unicode complet prise en charge du texte et de la mise en page. 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 vous permet de l’utiliser sur plusieurs plates-formes.
Caractéristiques DWriteCore contient toutes les fonctionnalités de DirectWrite, à quelques exceptions près.
Limitations importantes
DWriteCore ne contient pas les fonctionnalités DirectWrite suivantes : par session fontsEnd-user Defined Character (EUDC) fontsAPIs de streaming de policesLa prise en charge des API de rendu de bas niveau est partielle.DWriteCore n’interagit pas avec Direct2D, mais vous pouvez utiliser IDWriteGlyphRunAnalysis et IDWriteBitmapRenderTarget.
MRT Core
MRT Core est une version simplifiée de Windows moderne Système de gestion des ressources qui est distribué dans le cadre du SDK de l’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é créée. Pour contourner le problème, reconstruisez l’application. Voir issue 1503 pour plus d’informations. Dans les projets.NET, lorsqu’un fichier de ressources est ajouté à le projet à l’aide de l’interface utilisateur de Visual Studio, les fichiers peuvent ne pas être indexés par défaut. Voir issue 1786 pour plus d’informations. Pour contourner ce problème, veuillez supprimer les entrées ci-dessous dans le fichier CSPROJ :