Partager via

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.

Pour obtenir une vue d’ensemble du processus d’empaquetage, consultez empaqueter une application UWP avec Visual Studio.

Validation du manifeste d'application

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.

Voici un exemple de code XML de Identity sortie :

<Identity Name="Microsoft.UWPAppExample"
          Publisher="CN=Microsoft Corporation"
          Version="1.0.0.0"
          ProcessorArchitecture="x86" />

Propriétés

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 :

<Properties>
    <DisplayName>UWP App Example</DisplayName>
    <PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
</Properties>

Application

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++ :

<Dependencies>
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.30035.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>

extensions d’inscription de Windows Runtime

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 :

  • DllPath
  • ActivatableClassId
  • ThreadingModel
  • ActivatableClass (attribut ActivatableClassId)

Voici un exemple de sortie XML :

<extension category="Microsoft.Windows.ActivatableClass">
    <dllServer>
        <dllPath>Fabrikam.dll</dllPath>
        <activatableClass activatableClassId="Fabrikam.MyClass" threadingModel="sta" />
    </dllServer>
</extension>

pour plus d’informations sur cette rubrique, consultez Windows Runtime components.

Ressources

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 :

<Resources>
    <Resource Language="en-us">
    <Resource Language="fr-fr">
</Resources>

La première entrée de la liste est la langue par défaut de l'application.

TargetDeviceFamily

La TargetDeviceFamily section contient les champs suivants :

  • Nom
  • MinVersion
  • MaxVersionTested
<Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.0" />
</Dependencies>

ces éléments sont renseignés à partir des propriétés de MSBuild.

Voir aussi

Créer un package d’application UWP avec Visual Studio
Architectures de package d’application
Informations de référence sur le schéma du manifeste de package Windows 10