Configuration requise pour les packages d’application pour l’application MSIX

Spécifications

Suivez ces directives pour préparer les paquets de votre application pour les soumettre au Microsoft Store.

Avant de construire le paquet de votre application pour le Microsoft Store

Assurez-vous de tester votre application avec le Windows App Certification Kit. Nous vous recommandons également de tester votre application sur différents types de matériel. Veuillez noter que jusqu’à ce que nous certifiions votre application et qu’elle soit disponible dans Microsoft Store, celle-ci ne peut être installée et exécutée que sur des ordinateurs disposant de licences de développeur.

Construire le paquet de l’application en utilisant Microsoft Visual Studio

Si vous utilisez Microsoft Visual Studio comme environnement de développement, vous disposez déjà d’outils intégrés qui facilitent et accélèrent le processus de création d’un paquet d’application. Pour plus d’informations, consultez Empaquetage d’applications.

Lorsque vous créez votre paquet dans Visual Studio, assurez-vous d’être connecté avec le même compte associé à votre compte développeur. Certaines parties du manifeste du paquet ont des détails spécifiques liés à votre compte. Ces informations sont détectées et ajoutées automatiquement. Sans les informations supplémentaires ajoutées au manifeste, vous pourriez vous heurter à des échecs de téléchargement du paquet.

Lorsque vous construisez les paquets UWP de votre application, Visual Studio peut créer un fichier .msix ou .appx, ou un fichier .msixupload ou .appxupload. Pour les applications UWP, nous recommandons de toujours télécharger le fichier .msixupload ou .appxupload dans la page Paquets. Pour plus d’informations sur l’empaquetage des applications UWP pour le Store, veuillez consulter la section Empaqueter une application UWP avec Visual Studio.

Les paquets de votre application ne doivent pas être signés avec un certificat ayant sa racine dans une autorité de certification de confiance.

Paquets groupés

Pour les applications UWP, Visual Studio peut générer un paquet groupé (.msixbundle ou .appxbundle) pour réduire la taille de l’application que les utilisateurs téléchargent. Cela peut être utile si vous avez défini des ressources spécifiques à une langue, une variété d’actifs à différentes échelles d’image, ou des ressources qui s’appliquent à des versions spécifiques de Microsoft DirectX.

Avec un paquet groupé, un utilisateur téléchargera uniquement les fichiers pertinents, plutôt que toutes les ressources possibles. Pour plus d’informations sur les paquets groupés, veuillez consulter la section Empaqueter des applications et Empaqueter une application UWP avec Visual Studio.

Construire manuellement le paquet de l’application

Si vous n’utilisez pas Visual Studio pour créer votre paquet, vous devez créer votre manifeste de paquet manuellement.

Assurez-vous de consulter la documentation concernant le Manifeste de paquet d’application pour obtenir tous les détails et les conditions requises du manifeste. Votre manifeste doit suivre le schéma du manifeste de paquet pour passer la certification.

Votre manifeste doit inclure certaines informations spécifiques sur votre compte et votre application. Vous pouvez trouver ces informations en consultant la rubrique Voir les détails de l’identité de l’application dans la section Gestion du produit de la page de vue d’ensemble de votre application dans le tableau de bord.

Les paquets groupés (.msixbundle ou .appxbundle) utilisent un manifeste différent. Veuillez consulter la documentation intitulée Manifeste du paquet groupé concernant les détails et conditions requises des manifestes de paquets groupés. Veuillez noter que dans un .msixbundle ou .appxbundle, le manifeste de chaque paquet inclus doit utiliser les mêmes éléments et attributs, à l’exception de l’attribut ProcessorArchitecture de l’élément Identity.

Conditions requises pour le format du paquet

Les paquets de votre application doivent respecter ces exigences.

Versions prises en charge

Pour les applications UWP, tous les paquets doivent cibler une version de Windows 10 ou Windows 11 prise en charge par le Store. Les versions que votre paquet prend en charge doivent être indiquées dans les attributs MinVersion et MaxVersionTested de l’élément TargetDeviceFamily du manifeste de l’application.

Fichier XML StoreManifest

StoreManifest.xml est un fichier de configuration optionnel qui peut être inclus dans les paquets d’application. Son but est de permettre des fonctionnalités que le manifeste du paquet ne couvre pas comme déclarer votre application comme une application de périphérique Microsoft Store ou déclarer des conditions requises dont un paquet dépend pour être applicable à un périphérique. Si utilisé, StoreManifest.xml est soumis avec le paquet d’application et doit être dans le dossier racine du projet principal de votre application. Pour plus d’informations, veuillez consulter la section Schema StoreManifest.

Numérotation des versions de packages

Chaque package que vous fournissez doit avoir un numéro de version (fourni comme une valeur dans l’attribut Version de l’élément Package/Identité dans le manifeste de l’application). Microsoft Store applique certaines règles relatives aux numéros de version, qui fonctionnent un peu différemment selon les versions du système d’exploitation.

Numérotation des versions pour les packages Windows 10 et 11

Lorsque vous choisissez un package UWP à partir de votre soumission publiée, Microsoft Store utilisera toujours le package de la version la plus élevée applicable au dispositif Windows 10 ou Windows 11 du client. Cela vous donne une plus grande flexibilité et vous permet de contrôler quels packages seront fournis aux clients sur des types d’appareils spécifiques. Il est important de noter que vous pouvez soumettre ces packages dans n’importe quel ordre ; vous n’êtes pas limité à fournir des packages de version plus élevée à chaque soumission subséquente.

Vous pouvez fournir plusieurs packages UWP avec le même numéro de version. Cependant, les packages qui partagent un numéro de version ne peuvent pas également avoir la même architecture, car l’identité complète que Microsoft Store utilise pour chacun de vos packages doit être unique. Pour plus d’informations, veuillez consulter la section Identité.

Lorsque vous fournissez plusieurs packages UWP qui utilisent le même numéro de version, l’architecture (dans l’ordre x64, x86, Arm, neutre) sera utilisée pour décider lequel est de rang supérieur (lorsque Microsoft Store détermine quel package fournir à l’appareil d’un client). Lors du classement des lots d’applications qui utilisent le même numéro de version, le rang d’architecture le plus élevé dans le lot est choisi : un lot d’applications contenant un package x64 aura un rang supérieur à un qui contient uniquement un package x86.

Cela vous donne beaucoup de flexibilité pour faire évoluer votre application au fil du temps. Vous pouvez télécharger et soumettre de nouveaux packages utilisant des numéros de version inférieurs pour prendre en charge des dispositifs Windows 10 ou Windows 11 que vous n’avez pas précédemment pris en charge, vous pouvez ajouter des packages de version supérieure qui ont des dépendances plus strictes pour tirer parti des caractéristiques matérielles ou du système d’exploitation, ou vous pouvez ajouter des packages de version supérieure qui servent de mises à jour à une partie ou à la totalité de votre base de clients existante.

L’exemple suivant illustre comment la numérotation des versions peut être gérée pour livrer les packages destinés à vos clients sur plusieurs soumissions.

Exemple : Passer à un seul package sur plusieurs soumissions

Windows 10 vous permet d’écrire une base de code unique qui fonctionne partout. Cela rend le démarrage d’un nouveau projet multi plate-forme beaucoup plus simple. Cependant, pour un certain nombre de raisons, il est possible que vous ne souhaitiez pas fusionner les bases de code existantes pour créer un seul projet dans l’immédiat.

Vous pouvez utiliser les règles de contrôle de version des packages pour migrer progressivement vos clients vers un seul package pour la famille universelle d’appareils, tout en expédiant un certain nombre de mises à jour intermédiaires pour des familles d’appareils spécifiques (y compris celles qui tirent parti des API Windows 10). L’exemple ci-dessous illustre comment les mêmes règles sont appliquées de manière cohérente sur une série de soumissions pour la même application.

Utiliser la numérotation des versions pour revenir à un package précédemment expédié pour de nouvelles acquisitions

Si vous conservez des copies de vos packages, vous aurez l’option de revenir à un package plus ancien de votre application dans Microsoft Store pour Windows 10 si vous découvrez des problèmes avec une version. C’est une façon temporaire de limiter les perturbations pour vos clients pendant que vous prenez le temps de résoudre le problème.

Pour cela, créez une nouvelle soumission. Retirez le package problématique et téléchargez l’ancien package que vous souhaitez proposer dans Microsoft Store. Les clients ayant déjà reçu le package auquel vous revenez auront toujours le package problématique (puisque votre package plus ancien aura un numéro de version antérieur). Mais cela empêchera personne d’autre d’acquérir le package problématique, tout en permettant à l’application d’être toujours disponible dans Microsoft Store.

Pour résoudre le problème pour les clients ayant déjà reçu le package problématique, vous pouvez soumettre un nouveau package Windows 10 ayant un numéro de version supérieur à celui du mauvais package dès que possible. Après que cette soumission ait passé le processus de certification, tous les clients seront mis à jour vers le nouveau package, puisqu’il aura un numéro de version supérieur.

Langues prises en charge

Vous pouvez soumettre des applications au Microsoft Store dans plus de 100 langues.

Pour en savoir plus sur la configuration des langues dans vos applications, veuillez consulter a section Mondialisation et localisation et Comprendre les langues des profils utilisateur et les langues du manifeste de l’application. Nous disposons également d’un Kit d’outils multilingue pour application pour vous aider à écrire des applications prenant en charge plusieurs langues.

Liste des langues prises en charge

Ce sont les langues que le Microsoft Store prend en charge. Votre application doit prendre en charge au moins une de ces langues.

Les codes de langue qui ne sont pas inclus ici ne sont pas pris en charge par Microsoft Store. Nous vous recommandons de ne pas inclure de paquets ciblant des codes de langue autres que ceux listés ci-dessous ; de tels paquets ne seront pas distribués aux clients et peuvent causer des retards ou des échecs dans la certification.