Modifications apportées à Feature.xml

Dernière modification : lundi 12 juillet 2010

S’applique à : SharePoint Foundation 2010

La nouvelle section <UpgradeActions> dans un fichier Feature.xml spécifie les actions de mise à niveau que vous pouvez appliquer à un Composant fonctionnel spécifié.

Vous pouvez placer la section <UpgradeActions> au début ou à la fin du fichier Feature.xml, dans le contenu de l’élément <Feature>. Cette section vous permet de spécifier des actions de mise à niveau pour différentes plages de mise à niveau, et d’inclure une liste d’actions de mise à niveau applicables à une plage spécifiée. Les définitions de mise à niveau mettent systématiquement à niveau un Composant fonctionnel vers la version déclarée dans l’élément <Feature>.

Le code suivant montre un exemple de section <UpgradeActions> que vous pouvez définir dans un fichier Feature.xml.

<UpgradeActions 
  ReceiverAssembly="MyFeatureReceiver, 
  Version=1.0.0.0, 
  Culture=neutral, 
  PublicKeyToken=2f2197d99d6e2871" 
  ReceiverClass="FeatureReceiver.TestFeatureReceiver">
  <CustomUpgradeAction 
    Name="DeleteField">
    <Parameters>
      <Parameter 
        Name="FieldName">Address3
      </Parameter>
    </Parameters>
  </CustomUpgradeAction>
  <VersionRange 
    BeginVersion="2.0.0.0" 
    EndVersion="5.0.0.0">
      <!-- Here you specify other upgrade actions to apply to Feature instances whose versions are within the range 2.0.0.0 to 5.0.0.0 -->
  </VersionRange>
</UpgradeActions>

La section <UpgradeActions> indique comment mettre à niveau une instance de Composant fonctionnel. Vous pouvez réaliser les scénarios de mise à niveau courants de façon déclarative en modifiant simplement le fichier Feature.xml, tandis que les scénarios plus avancés peuvent vous amener à implémenter la méthode FeatureUpgrading(SPFeatureReceiverProperties, String, IDictionary<String, String>) pour mettre en œuvre une logique de mise à niveau de Composant fonctionnel personnalisée. Pour plus d’informations sur les éléments déclaratifs, voir « Étendue et mise en service des manifestes d’éléments ».

L’élément <UpgradeActions> peut contenir les sous-éléments suivants :

• <CustomUpgradeAction> : permet d’exécuter du code personnalisé lorsqu’une instance de Composant fonctionnel en est cours de mise à niveau. Lorsqu’une action est spécifiée dans une séquence d’actions de mise à niveau, Microsoft SharePoint Foundation appelle la méthode FeatureUpgrading(SPFeatureReceiverProperties, String, IDictionary<String, String>) de façon synchrone avec les autres actions de mise à niveau, dans l’ordre de la déclaration.

• <VersionRange> : spécifie une plage de versions à laquelle s’appliquent des actions de mise à niveau spécifiées.

• <ApplyElementManifests> : ajoute un nouvel élément à un Composant fonctionnel existant. Lorsqu’un Composant fonctionnel est mis à niveau, ce sous-élément met en service tous les éléments non déclaratifs référencés dans les manifestes d’éléments spécifiés.

• <AddContentTypeField> : ajoute un nouveau champ à un type de contenu mis en service existant. Propage la modification depuis le type de contenu de site à la totalité des listes et des types de contenu enfants dans le site. Par exemple :

  <AddContentTypeField 
    ContentTypeId="0x010100A6F9CE1AFE2A48f0A3E6CB5BB770B0F7" 
    FieldId="{B250DCFD-9310-4e2d-85F2-BE2DA37A57D2}" 
    PushDown="TRUE" />
  

  Dans la plupart des cas, les valeurs des attributs ContentTypeId et FieldId sont spécifiées dans le fichier Elements.xml où sont définis le type de contenu et le champ.

• <MapFile> : permet de mapper un fichier non personnalisé à un emplacement différent sur le serveur Web frontal. Vous pouvez utiliser les attributs FromPath et ToPath pour renommer un fichier dans un Composant fonctionnel (par exemple, <MapFile FromPath=”oldname.gif” ToPath=”newname.gif” />, mais vous pouvez également utiliser MapFile pour déplacer un fichier. Dans ce cas, les attributs FromPath et ToPath spécifient des chemins d’accès relatifs au répertoire TEMPLATE. Par exemple, si un Composant fonctionnel nommé « MonComposantFonctionnel » possède des fichiers .gif qui sont installés dans un répertoire « Gifs » (par exemple, %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES\MonComposantFonctionnel\Gifs\basketball.gif) et que dans la version 2 vous souhaitez renommer le répertoire « Gifs » en « Images », vous pouvez utiliser <MapFile FromPath=”Gifs\ball.gif” ToPath=”Images\basketball.gif” /> pour déplacer les fichiers.

Pour que vous puissiez facilement utiliser des dépendances de fonctionnalités avec version, l’attribut MinimumVersion a été ajouté à l’élément <ActivationDependency>, utilisé lorsqu’un Composant fonctionnel dépend d’un autre Composant fonctionnel dont le numéro de version doit être supérieur ou égal à la valeur de l’attribut MinimumVersion.

Étendue et mise en service des manifestes d’éléments

Le tableau suivant montre les étendues au niveau desquelles un élément de Composant fonctionnel spécifique est valide et indique si l’élément est mis en service lorsque le Composant fonctionnel est activé ou si sa mise en service est annulée lorsque le Composant fonctionnel est désactivé.

Comme indiqué dans le tableau, l’élément <CustomAction> est disponible au niveau de toutes les étendues : Web (site Web), Site (collection de sites), WebApplication et Farm (batterie de serveurs). Il s’agit d’un élément déclaratif qui n’est pas mis en service et dont la mise en service n’est pas annulée, ce qui signifie qu’il est directement mis en cache dans la mémoire à partir de la définition XML du Composant fonctionnel, sans qu’aucune logique de mise en service s’exécute pendant l’activation du Composant fonctionnel. Par conséquent, une fois que vous avez activé le Composant fonctionnel et que vous accédez à une page qui contient l’action personnalisée, celle-ci est chargée à partir du cache, puis affichée dans la page. L’élément Field est uniquement valide dans l’étendue collection de sites. Il est mis en service lors de l’activation (création de la colonne de site) et sa mise en service est annulée lors de la désactivation (suppression de la colonne de site). L’élément <ListInstance> est valide dans les étendues Web et collection de sites. Il est mis en service lors de l’activation (création de l’instance de liste), mais sa mise en service n’est pas annulée lors de la désactivation (non-suppression de l’instance de liste).