Fusionner du code XML dans des manifestes de fonctionnalités et de packages
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
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour