Microsoft Windows App SDK 1.0 Stable publié, disponible au téléchargement (Notes de version)

Accueil » #Repost

Icône de temps de lecture 12 minute. lis

Icône de calendrier Mis à jour le

by Surur Davids 

mis à jour le

Partagez cet article

Les lecteurs aident à prendre en charge MSpoweruser. Nous pouvons recevoir une commission si vous achetez via nos liens. Icône d'info-bulle

Lisez notre page de divulgation pour savoir comment vous pouvez aider MSPoweruser à soutenir l'équipe éditoriale En savoir plus

winUI

Après plusieurs versions d'aperçu, 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 a stabilisé les problèmes des versions 1.0 Preview.

[lwptoc title=”WindowsAppSDK 1.0 Stable” width=”30%” float=”right”]

WindowsUI 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 WindowsUI 2.6.
  • L'empaquetage MSIX à projet unique est pris en charge dans WinUI en créant une nouvelle application à l'aide du modèle "Application vierge, empaqueté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 une application de bureau WinUI 3 non compressée pour d’autres renseignements. 
  • Les projets WinUI 3 peuvent désormais définir leur version cible sur Windows 10, version 1809. Auparavant, ils ne pouvaient être définis que sur la version 1903.
  • La barre d'outils intégrée à l'application, le rechargement à chaud et l'arbre visuel en direct pour les applications packagées WinUI sont pris en charge dans Visual Studio 2022 Preview 5 et GA.

Limites importantes:

  • Problèmes connus pour applications WinUI packagées et non packagées:
    • Erreur d'exécution dans les applications C++ qui font référence à un composant d'exécution Windows C++ : Pour résoudre le problème, ajoutez la cible ci-dessous à la fin du fichier .vcxproj du composant Windows Runtime :

      XML

      <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>
  • Problèmes connus pour Applications WinUI avec MSIX à projet unique (Application vierge, modèle packagé) :
    • Élément de menu Package & Publier manquant jusqu'au redémarrage de Visual Studio : Lors de la création d'une nouvelle application avec MSIX à projet unique dans Visual Studio 2019 et Visual Studio 2022 à l'aide du modèle de projet Application vierge, packagée (WinUI 3 dans Desktop), la commande de publication du projet n'apparaît pas dans le menu jusqu'à ce que vous fermiez et rouvrez Visual Studio.
    • L'application AC# avec MSIX à projet unique ne sera pas compilée sans le composant facultatif "C++ (v14x) Universal Windows Platform Tools" installé. Voir Installer les outils de développement pour d’autres renseignements. 
    • Erreur d'exécution potentielle dans une application avec MSIX à projet unique qui consomme des types définis dans un composant d'exécution Windows référencé : Pour résoudre, ajoutez manuellement entrées de classe activables au fichier appxmanifest.xml.
      • L'erreur attendue dans les applications C# est "COMException : Classe non enregistrée (0x80040154 (REGDB_E_CLASSNOTREG)).
      • L'erreur attendue dans les applications C++/WinRT est "winrt::hresult_class_not_registered".
  • Problèmes connus pour Applications WinUI sans package MSIX (applications non packagées) :
  • Problèmes connus pour empaqueter et déployer des applications WinUI:
    • Les Package La commande n'est pas prise en charge dans les applications WinUI avec MSIX à projet unique (application vierge, modèle intégré). Utilisez plutôt le Package & Publish commande pour créer un package MSIX.
    • Pour créer un package NuGet à partir d'une bibliothèque de classes C# avec le Pack commande, assurez-vous que la Configuration is Release.
    • Les Pack La commande n'est pas prise en charge dans les composants C++ Windows Runtime pour créer un package NuGet.

Fenêtrage

Le SDK d'application Windows fournit un Fenêtre d'application classe qui fait évoluer la précédente classe d'aperçu Windows.UI.WindowManagement.AppWindow facile à utiliser et la rend disponible pour toutes les applications Windows, y compris Win32, WPF et WinForms.

Nouvelles fonctionnalités

  • Fenêtre d'application 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'expérience utilisateur Windows 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 familiarisés avec Win32, l'AppWindow peut être considérée comme une abstraction de haut niveau du HWND.
  • Zone d'affichage représente une abstraction de haut niveau d'un HMONITOR, suit les mêmes principes que AppWindow.
  • DisplayAreaWatcher permet à un développeur d'observer les changements dans la topologie d'affichage et d'énumérer les zones d'affichage actuellement définies dans le système.

Entrée

Ce sont les API d'entrée qui prennent en charge WinUI et fournissent une surface d'API de niveau inférieur aux développeurs pour obtenir des interactions d'entrée plus avancées.

Nouvelles fonctionnalités

  • API de pointeur : Pointeur, PropriétésPointerPointet PointerEventArgsPointerEventArgs 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 enregistré pour signaler l'entrée du pointeur et fournit la gestion du curseur du pointeur et des événements d'entrée pour l'API SwapChainPanel de XAML.
  • API de curseur: permet aux développeurs de modifier le bitmap du curseur.
  • API GestureRecognizer: permet aux développeurs de reconnaître certains gestes tels que glisser, maintenir et cliquer lorsqu'ils reçoivent des informations sur le pointeur.

Limites importantes

  • Tous Pointeur les fonctions d'usine statiques ont été supprimées : ObtenirPointCurrent, ObtenirPointCurrentTransformé, Obtenir des points intermédiaireset GetIntermediatePointsTransformed.
  • Le SDK d'application Windows ne prend pas en charge la récupération Pointeur objets avec des ID de pointeur. Au lieu de cela, vous pouvez utiliser le Pointeur fonction membre ObtenirPointTransformé pour récupérer une version transformée d'un existant Pointeur objet. Pour les points intermédiaires, vous pouvez utiliser le PointerEventArgsPointerEventArgs fonctions des membres Obtenir des points intermédiaires ainsi que le GetTransformedIntermediatePoints.
  • Utilisation directe de l'API SDK de la plateforme Windows.UI.Core.CoreDragOperationWindows.UI.Core.CoreDragOperation ne fonctionnera pas avec les applications WinUI.
  • Pointeur propriétés Position brute ainsi que le ContacterRectRaw ont été supprimés car ils 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 ainsi que le ContactRect plutôt. La prédiction de pointeur est maintenant gérée avec le Microsoft.UI.Input.PointerPredictorMicrosoft.UI.Input.PointerPredictor Objet API.

Cycle de vie de l'application

La plupart des fonctionnalités du cycle de vie des applications existent déjà dans la plate-forme UWP et ont été intégrées au SDK d'applications Windows pour être utilisées par les types d'applications de bureau, en particulier les applications de console non empaquetées, les applications Win32, les applications Windows Forms et les applications WPF. L'implémentation Windows App SDK 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 Windows App SDK.

Les applications non UWP peuvent également être regroupées dans des packages MSIX. Bien que ces applications puissent utiliser certaines des fonctionnalités du cycle de vie de l'application Windows App SDK, elles doivent utiliser l'approche du manifeste lorsqu'elle est disponible. Par exemple, ils ne peuvent pas utiliser le SDK d'application Windows S'inscrirePourXXXActivation API 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 packagées, et il existe des considérations supplémentaires, comme décrit ci-dessous.

Considérations importantes:

  • Activation riche : GetActivatedEventArgs
  • S'inscrire/Se désinscrire pour l'activation enrichie
    • Applications non packagées: Entièrement utilisable.
    • Applications packagées: Inutilisable, utilisez plutôt le manifeste MSIX de l'application.
    • Pour plus d'informations, voir Activation riche.
  • Instanciation unique/multiple
    • Applications non packagées: Entièrement utilisable.
    • Applications packagées: Entièrement utilisable.
    • Applications WinUI : Si une application souhaite détecter d'autres instances et rediriger une activation, elle doit le faire le plus tôt possible et avant d'initialiser des fenêtres, etc. WinMain (C++) où il peut faire la détection et la redirection.
    • RedirectionActivationToAsync 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 C# WinUI, vous pouvez déclarer Main comme étant asynchrone, si nécessaire. Pour les applications C++ WinUI et C# WPF, vous ne pouvez pas déclarer Main comme étant asynchrone, vous devez donc plutôt 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/d'état
    • Applications non packagées: Entièrement utilisable.
    • Applications packagées: Entièrement utilisable.
    • Pour plus d'informations, voir Gestion de l'alimentation.

Problème connu:

  • Les associations de type de fichier codent incorrectement %1 pour être %251 lors de la définition du modèle de ligne de commande du gestionnaire Verb, ce qui bloque les applications Win32 décompressé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 un espace, il échouera toujours et il n'y a pas de solution de contournement pour ce scénario.
  • Ces bogues d'instanciation simple/multiple seront corrigés dans un prochain correctif de maintenance :
    • La redirection AppInstance ne fonctionne pas lorsqu'elle est compilée pour x86
    • Enregistrer une clé, la désenregistrer et la réenregistrer provoque le blocage de l'application

DWriteCoreComment

DWriteCore est l'implémentation Windows App SDK de Écriture directe, qui est l'API DirectX pour un rendu de texte de haute qualité, des polices vectorielles indépendantes de la résolution et une prise en charge complète du texte et de la mise en page Unicode. 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.

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

Limites importantes

  • DWriteCore ne contient pas les fonctionnalités DirectWrite suivantes :
    • Polices par session
    • Polices de caractères définis par l'utilisateur final (EUDC)
    • API de diffusion 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 ainsi que le IDWriteBitmapRenderTargetIDWriteBitmapRenderTarget.

Noyau MRT

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.

Limites 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 émettre 1503 pour plus d'informations.
  • 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. Voir émettre 1786 pour plus d'informations. Pour contourner ce problème, veuillez supprimer les entrées ci-dessous dans le fichier CSPROJ :

    XML

    <ItemGroup>
    <Content Remove="<image file name>" />
</ItemGroup>
<ItemGroup>
    <PRIResource Remove="<resw file name>" />
</ItemGroup>
  • Pour les applications C++ WinUI non empaquetées, l'URI de la ressource n'est pas créée correctement. Pour contourner ce problème, ajoutez les éléments suivants dans vcxproj :

    XML

    <!-- Add the following after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> -->

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

Déploiement

Nouvelles fonctionnalités et mises à jour

  • Vous pouvez initialiser automatiquement le SDK d'application Windows via le WindowsPackageType project propriété pour charger le runtime Windows App SDK et appeler les API Windows App SDK. Voir Créer une application WinUI 3 pour obtenir des instructions.
  • Les applications non empaquetées peuvent déployer le SDK d'application Windows en s'intégrant dans le SDK d'application Windows autonome .exe programme d'installation dans votre MSI ou programme d'installation existant. Pour plus d'informations, voir Guide de déploiement du SDK d'application Windows pour les applications non empaquetées.
  • Les applications .NET non empaquetées peuvent également utiliser le wrapper .NET pour le API d'amorçage pour prendre dynamiquement une dépendance sur le package d'infrastructure Windows App SDK au moment de l'exécution. Pour plus d'informations sur le wrapper .NET, voir bibliothèque d'encapsulation .NET.
  • Les applications packagées peuvent utiliser l'API de déploiement pour vérifier et s'assurer que tous les packages requis sont installés sur la machine. Pour plus d'informations sur le fonctionnement de l'API de déploiement, consultez le guide de déploiement pour les applications packagées.

Limites importantes

  • Le wrapper .NET pour l'API d'amorçage est uniquement destiné à être utilisé par des applications .NET non empaquetées pour simplifier l'accès au SDK d'application Windows.
  • Seules les applications packagées MSIX qui sont entièrement fiables ou qui ont le Gestion des packages restreint ont l'autorisation d'utiliser l'API de déploiement pour installer les dépendances de package principal et singleton. La prise en charge des applications packagées à confiance partielle sera disponible dans les versions ultérieures.
  • Lorsque F5 teste une application x86 qui utilise le DeploymentManager.Initialize sur un système x64, assurez-vous que le framework x64 est d'abord installé en exécutant la WindowsAppRuntimeInstall.exe. Sinon, vous rencontrerez un PAS TROUVÉ erreur due au fait que Visual Studio ne déploie pas le framework x64, ce qui se produit normalement via le déploiement du magasin ou le chargement latéral.

Autres limitations et problèmes connus

  • Pas de prise en charge de toute configuration de build de CPU: Quand ajout du 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 or arm64.
  • Mise à niveau de .NET 5 vers .NET 6: lors de la mise à niveau dans l'interface utilisateur de Visual Studio, vous pouvez rencontrer des erreurs de génération. Pour contourner le problème, mettez à jour manuellement le TargetFrameworkPackage de votre fichier de projet comme suit :

    XML

        <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework>
  • L'application MSIX à projet unique C# ne se compile pas si les outils C++ UWP ne sont pas installés. Si vous avez un projet MSIX à projet unique C#, vous devrez installer le Outils de plate-forme Windows universelle C++ (v14x) composant facultatif.
  • La langue suivante VSIX 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, Release et Preview), puis installez le SDK d'application Windows VSIX pour C++ ainsi que le C#, la deuxième installation échouera. Pour résoudre le problème, désinstallez les outils de packaging MSIX à projet unique pour Visual Studio 2019 après la première langue VSIX. Voir cette rétroaction pour plus d'informations sur ce problème.
  • Si tu veux co_await sur le DispatcherQueue.TryEnqueueDispatcherQueue.TryEnqueue méthode, puis utilisez la CV_foreground fonction d'assistance dans le Bibliothèque d'implémentation Windows (WIL):
    1. Ajouter une référence à Microsoft.Windows.ImplementationLibraryMicrosoft.Windows.ImplementationLibrary package NuGet.
    2. Ajoutez le #include <wil/cppwinrt_helpers.h> déclaration à votre fichier de code.
    3. Utilisez wil::resume_foreground(your_dispatcher); à co_await le résultat.

En savoir plus et trouver les liens de téléchargement sur Microsoft ici.

En savoir plus sur les sujets : SDK d'application Windows 1.0.0, winui 3

Surur Davids

Surur Davids bouclier

Expert en smartphones

Surur Davids est le fondateur de WMPoweruser qui deviendra plus tard MSPoweruser.com. C'est un expert en smartphones avec plus d'une décennie d'expérience.