Comment Visual Studio génère un manifeste de package d’application
Article
quand vous générez un projet avec Visual Studio, Visual Studio génère un manifeste de package (AppxManifest.xml), qui contient les informations dont le système a besoin pour déployer, afficher ou mettre à jour une application plateforme Windows universelle (UWP).
Il existe deux types de fichiers manifestes de package d’application que vous rencontrerez si vous développez une application avec Visual Studio
Package.appxmanifest
Il s’agit d’un fichier de style XML que les développeurs utilisent pour configurer les détails d’une application, tels que les informations sur le serveur de publication, les logos, les architectures de processeur, etc. Il s’agit d’une version temporaire configurable et facile du manifeste du package d’application utilisé pendant le développement de l’application.
AppxManifest.xml
ce fichier est généré par le processus de génération Visual Studio et est basé sur les informations contenues dans le fichier Package. appxmanifest. Il s’agit de la version finale du manifeste de package d’application utilisé avec les applications publiées et faisant. Si des mises à jour sont apportées au fichier Package. appxmanifest, vous devez régénérer le projet pour afficher les mises à jour dans le fichier de AppxManifest.xml.
Avant de pouvoir publier votre application, vous devez corriger les erreurs qui provoquent l’échec des contrôles de validation Visual Studio. Lorsque Visual Studio génère le manifeste, Visual Studio valide votre application comme suit :
Validation syntaxique
Visual Studio confirme si toutes les données dans le manifeste d'application sont conformes au schéma du manifeste d'application.
Validation sémantique
Visual Studio fournit des instructions quant aux données attendues, selon le contexte des informations.
Notes
Si ces sections ne mentionnent pas le champ que vous recherchez, elles sont générées à partir de données qui ont pu être configurées séparément ou d’une valeur par défaut à partir du schéma de manifeste.
Génération du contenu du manifeste
Visual Studio remplit les champs dans les tables suivantes lorsqu’il génère le fichier AppxManifest.xml pour le package d’application.
Identité
La Identity section du manifeste de l’application contient les champs suivants.
Champ
Description
Nom
Nom du package, qui est renseigné différemment dans les scénarios suivants :
Par défaut, la valeur de ce champ est un GUID généré.
si vous associez l’application au Microsoft Store, ou si vous appelez la commande Store- > créer des Packages d’application... , puis que vous vous connectez avec un compte de développeur, la valeur de ce champ est extraite de l’application associée dans le Microsoft Store ou l’espace partenaires.
Si vous appelez la commande Store- > créer des packages d’application... mais ne vous connectez pas avec un compte de développeur, la valeur de ce champ est extraite du manifeste source.
Serveur de publication
Nom de l'éditeur. Ce nom est renseigné différemment dans les scénarios suivants :
Par défaut, la valeur de ce champ est votre nom d'utilisateur.
si vous associez l’application au Microsoft Store, ou si vous appelez la commande Store- > créer des Packages d’application... , puis que vous vous connectez avec un compte de développeur, la valeur de ce champ est le serveur de publication associé au compte.
Si vous appelez la commande Store- > créer des packages d’application... mais ne vous connectez pas avec un compte de développeur, la valeur de ce champ correspond au champ objet du certificat de test que vous avez utilisé pour signer le package d’application.
Visual Studio prend en charge uniquement le format de nom commun (cn) pour le serveur de publication et ajoute le préfixe « CN = » au champ serveur de publication dans le manifeste.
Version
Version de l’application en cours de génération. Cela est généralement incrémenté chaque fois que l’application a été modifiée et empaquetée. Pour vous assurer que le Version est correctement incrémenté, utilisez la boîte de dialogue fournie lors de l’appel de packages d’application Store- > créer... pour effectuer des mises à jour.
ProcessorArchitecture
Valeur générée en fonction de la configuration de build que vous avez spécifiée pour le projet. Si des références de projet ou des références de fichier dans le projet ciblent une architecture différente de celle du package d’application, une erreur de génération est générée et vous devez modifier l’architecture cible du package d’application pour qu’elle fonctionne pour toutes les références.
La Properties section du manifeste de l’application contient les champs dans le tableau suivant.
Champ
Description
PublisherDisplayName
Cette chaîne est remplie différemment dans les scénarios suivants :
Par défaut, la valeur de ce champ est votre nom d'utilisateur.
si vous associez l’application au Microsoft Store, ou si vous appelez la commande Store- > créer des Packages d’application... , puis que vous vous connectez avec un compte de développeur, la valeur de ce champ correspond à la chaîne PublisherDisplayName associée à votre compte de développeur.
Si vous appelez la commande Store- > créer des packages d’application... mais ne vous connectez pas avec un compte de développeur, la valeur de ce champ est votre nom d’utilisateur, sauf indication contraire dans le fichier Package. appxmanifest.
DisplayName
Cette chaîne est renseignée différemment dans les scénarios suivants :
Par défaut, la valeur de ce champ est le nom du projet.
si vous associez l’application au Microsoft Store, ou si vous appelez la commande Store- > créer des Packages d’application... , puis que vous vous connectez avec un compte de développeur, la valeur de ce champ est renseignée selon les règles suivantes :
Si vous spécifiez cette valeur dans le manifeste source et que la valeur commence par @ (ce qui indique que vous souhaitez localiser cette valeur), la valeur de ce champ correspond à ce que vous avez spécifié.
Si l'application sélectionnée n'a qu'un seul nom, la valeur correspond à ce nom.
Si l’application sélectionnée a plusieurs noms, mais que le manifeste source n’est pas localisé, la valeur est définie sur le nom complet dans le manifeste source. Sinon, la valeur est le premier nom réservé.
Si vous appelez la commande Store- > créer des packages d’application... mais ne vous connectez pas avec un compte de développeur, la valeur de ce champ est extraite du manifeste source.
Logo
un modèle de Visual Studio sera utilisé Assets\StoreLogo.png par défaut. Cette valeur doit être personnalisée par le développeur dans le fichier Package. appxmanifest.
Voici un exemple de code XML de Properties sortie :
Un manifeste d’application peut contenir plusieurs Application éléments, chacun d’eux ayant un nom d’affichage qui apparaît sur la vignette dans le client. La Application section du manifeste de l’application contient les champs dans le tableau suivant.
Champ
Description
Id
Cette chaîne est renseignée différemment dans les scénarios suivants :
Par défaut, la valeur de ce champ est le nom du projet.
si vous associez l’application au Microsoft Store, ou si vous appelez la commande Store- > créer des Packages d’application... , puis que vous vous connectez avec un compte de développeur, la valeur de ce champ est le nom de l’application sélectionnée si le /Properties[@DisplayName] et le /Applications/Application[@DisplayName] du manifeste source correspondent. Sinon, la valeur reste la même que dans le manifeste source.
Si vous appelez la commande Store- > créer des packages d’application... mais ne vous connectez pas avec un compte de développeur, la valeur de ce champ est la même que dans le manifeste source.
Exécutable
La valeur de ce champ est le nom de sortie de l'assembly du projet. Le jeton exécutable $targetnametoken $.exe qui est utilisé dans le fichier manifeste source (package. appxmanifest) est remplacé par le nom de fichier réel lors de la génération du manifeste.
EntryPoint
Cette valeur est basée sur les valeurs et Id générées Executable .
Exemple Application de sortie :
<Applications>
<Application Id="App" Executable="UWPAppExample.exe" EntryPoint="UWPAppExample.App">
<!-- Other elements configured within the Application, such as Extensions, VisualElements, etc. -->
</Applications>
PackageDependency
la PackageDependency section contient toutes les dépendances de la bibliothèque de composants Windows pour ce package. par exemple, si votre projet a une référence à WinJS, Visual Studio récupère les informations d’identité du package des dépendances lors de la génération du manifeste. Visual Studio remplit ensuite cette section avec les Name champs et MinVersion pour chaque package dépendant.
dans un projet C++ natif, Visual Studio ajoute une référence au Runtime Visual C/C++ :
vous pouvez implémenter des composants de Windows Runtime pour vos applications, mais vous devez inscrire ces composants auprès du système d’exploitation pour qu’ils s’exécutent correctement. pour inscrire un composant Windows Runtime, vous devez placer les informations d’inscription dans les fichiers WinMD et dans le manifeste de l’application. si un projet implémente un composant Windows Runtime, la sortie de génération du projet contient un fichier WinMD. Visual Studio extrait les informations d’inscription Windows Runtime à partir du fichier WinMD et génère les éléments appropriés Extension dans le manifeste de l’application.
Le système prend en charge deux formes de serveurs : les serveurs .dll (in-process) et les serveurs .exe (out-of-process). Ces serveurs nécessitent des informations d'inscription semblables, mais différentes, qui doivent être copiées dans le manifeste d'application. Visual Studio prend en charge la génération de manifeste uniquement pour les serveurs .dll, et l'extension DLLServer est nécessaire pour inscrire les serveurs .dll. Les valeurs suivantes dans le manifeste d’application sont extraites des fichiers WinMD pour générer l’extension DLLServer :
La Resources section contient une entrée pour chaque langue prise en charge par l’application. Vous devez avoir au moins une langue de ressource spécifiée dans le manifeste de l’application. Visual Studio génère automatiquement la liste des langues prises en charge en fonction des informations de localisation dans le projet. Le jeton de langage de ressource « x-Generate » utilisé dans le fichier manifeste source (package. appxmanifest) est remplacé par le code de langue réel lors de la génération du manifeste. Voici un exemple de sortie XML :