Fusionner du code XML dans des manifestes de fonctionnalités et de packages

  • Article

Les fonctionnalités et les packages sont définis par des fichiers manifeste XML. Ces manifestes empaquetés sont une combinaison de données générées à partir de XML de concepteurs et personnalisé entré dans le modèle de manifeste par les utilisateurs. Au moment de l’empaquetage, Visual Studio fusionne les instructions XML personnalisées avec le code XML fourni par le concepteur pour former le fichier manifeste XML empaqueté. Des éléments similaires, avec les exceptions indiquées plus loin dans Exceptions de fusion, sont fusionnés pour éviter les erreurs de validation XML après le déploiement des fichiers dans SharePoint, et pour rendre les fichiers manifestes plus petits et plus efficaces.

Modifier les manifestes

Vous ne pouvez pas modifier directement les fichiers manifeste empaquetés tant que vous n’avez pas désactivé les concepteurs de fonctionnalités ou de packages. Toutefois, vous pouvez ajouter manuellement des éléments XML personnalisés au modèle de manifeste par le biais des concepteurs de fonctionnalités et de packages ou de l’éditeur XML. Pour plus d’informations, voir Guide pratique pour personnaliser une fonctionnalité SharePoint et Guide pratique pour personnaliser un package de solution SharePoint.

Processus de fusion de manifeste de fonctionnalité et de package

Lors de la combinaison d’éléments personnalisés avec des éléments fournis par le concepteur, Visual Studio utilise le processus suivant. Visual Studio vérifie si chaque élément a une valeur de clé unique. Si un élément n’a pas de valeur de clé unique, il est ajouté au fichier manifeste empaqueté. De même, les éléments qui ont plusieurs clés ne peuvent pas être fusionnés. Par conséquent, ils sont ajoutés au fichier manifeste.

Si un élément a une clé unique, Visual Studio compare les valeurs du concepteur et des clés personnalisées. Si les valeurs correspondent, elles fusionnent en une seule valeur. Si les valeurs diffèrent, la valeur de la clé de concepteur est ignorée et la valeur de clé personnalisée est utilisée. Les collections sont également fusionnées. Par exemple, si le code XML généré par le concepteur et le code XML personnalisé contiennent une collection Assemblies, le manifeste empaqueté ne contient qu’une seule collection Assemblies.

Fusionner des exceptions

Visual Studio fusionne la plupart des éléments XML du concepteur avec des éléments XML personnalisés similaires, à condition qu’ils aient un seul attribut d’identification unique. Toutefois, certains éléments ne disposent pas de l’identificateur unique requis pour la fusion XML. Ces éléments sont appelés exceptions de fusion. Dans ce cas, Visual Studio ne fusionne pas les éléments XML personnalisés avec les éléments XML fournis par le concepteur, mais les ajoute au fichier manifeste empaqueté.

Voici une liste d’exceptions de fusion pour les fichiers manifeste XML de fonctionnalité et de package.

Concepteur Élément XML
Concepteur de fonctionnalités ActivationDependency
Concepteur de fonctionnalités UpgradeAction
Concepteur de package SafeControl
Concepteur de package CodeAccessSecurity

Éléments du manifeste de fonctionnalité

Le tableau suivant répertorie tous les éléments de manifeste de fonctionnalité qui peuvent être fusionnés et leur clé unique utilisée pour la correspondance.

Nom de l’élément Clé unique
Fonctionnalité (tous les attributs) Nom de l’attribut (Chaque nom d’attribut de l’élément Feature est une clé unique.)
ElementFile Emplacement
ElementManifests/ElementManifest Emplacement
Properties/Property Clé :
CustomUpgradeAction Nom
CustomUpgradeActionParameter Nom

Notes

Étant donné que la seule façon de modifier l’élément CustomUpgradeAction est dans l’éditeur XML personnalisé, l’effet de ne pas fusionner est faible.

Éléments du manifeste de package

Le tableau suivant répertorie tous les éléments de manifeste de fonctionnalité qui peuvent être fusionnés et leur clé unique utilisée pour la correspondance.

Nom de l’élément Clé unique
Solution (tous les attributs) Nom de l’attribut (Chaque nom d’attribut de l’élément Solution est une clé unique.)
ApplicationResourceFiles/ApplicationResourceFile Emplacement
Assemblys/Assembly Emplacement
ClassResources/ClassResource Emplacement
DwpFiles/DwpFile Emplacement
FeatureManifests/FeatureManifest Emplacement
Ressources/Ressource Emplacement
RootFiles/RootFile Emplacement
SiteDefinitionManifests/SiteDefinitionManifest Emplacement
WebTempFile Emplacement
TemplateFiles/TemplateFile Emplacement
SolutionDependency SolutionID

Ajouter manuellement des fichiers déployés

Certains éléments de manifeste, tels que ApplicationResourceFile et DwpFiles, spécifient un emplacement qui inclut un nom de fichier. Toutefois, l’ajout d’une entrée de nom de fichier au modèle de manifeste n’ajoute pas le fichier sous-jacent au package. Vous devez ajouter le fichier au projet pour l’inclure dans le package et définir sa propriété Type de déploiement en conséquence.

Contenu connexe