Avec SharePoint 2010 nous avons la possibilité de gérer des numéros de version sur nos « features » et d’avoir sur une même ferme, une même « feature » activée avec des versions différentes.
Comment cela est-il rendu possible ? Tout d’abord en insérant dans votre « feature.xml » un numéro de version initiale (j’ai choisi « 1.0.0.0 »).
Une fois ma solution validée, je la déploie comme d’habitude sur mon serveur. J’ai ainsi dans mon répertoire 14, un ensemble de « feature » en version 1.0.0.0 dont celle-ci dessus qui déploie la WebPart suivante :
Cette « feature » est constituée d’un fichier manifest classique (SAPViewerWebPart\Element.xml) qui informe SharePoint des actions à effectuer et de la définition de la WebPart (SAPViewerWebPart\SAPViewerWebPart.webpart). Ce qui est important ici de comprendre étant que lors de l’activation, SharePoint récupère le numéro de version et le garde précieusement dans la base de contenu du site, afin de pouvoir savoir sous quel numéro de version cette « feature » a été activée.
Maintenant si je reviens en environnement de développement, et que je souhaite rajouter une WebPart dans l’optique d’une mise à niveau de ma fonctionnalité, il faut dans un premier temps déjà modifier le numéro de version dans le fichier « Site.WebParts.Template.xml » ici en exemple 1.0.0.1. Ensuite il faut surtout que je donne le moyen à SharePoint de passer d’une version 1.0.0.0 en 1.0.0.1.
I – Présentation des possibilités pour l’upgrade
Pour faire cette distinction, SharePoint nous invite à renseigner une section UpgradeActions dans le « Site.WebParts.Template.xml » de cette forme :
<UpgradeActions ReceiverAssembly="MyFeatureReceiver, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3e1b35c83d6e53f4"
ReceiverClass="MyFeatureReceiver.MyFeatureReceiver">
<VersionRange BeginVersion="1.0.0.0" EndVersion="1.0.0.1">
<ApplyElementManifests>
<ElementManifest Location="WebPart\Manifest.xml"/>
</ApplyElementManifests>
<AddContentTypeField ContentTypeId=""
FieldId=""
PushDown="TRUE" />
<CustomUpgradeAction Name="UpgradeTo1001">
<Parameters>
<Parameter Name="Parametre1">Valeur1</Parameter>
</Parameters>
</CustomUpgradeAction>
</VersionRange>
</UpgradeActions>
Dans l’ordre :
1- Toutes les sections de mise à niveau commencent par <UpgradeActions>, les attributs ReceiverAssembly et ReceiverClass permettent de spécifier une classe qui va être appelée si nous avons un CustomUpgradeAction (mise à niveau par le code finalement)
2- La section ApplyElementManifests permet d’appliquer une définition xml lors de la mise à jour
3- AddContentTypeField est très utile si on souhaite juste rajouter un champ à un type de contenu, PushDown permettant de propager la modification à tous les types de contenu
4- CustomUpgradeAction permet de spécifier une action particulière par le code lors de la mise à niveau.
Voici un exemple de définition pour la classe en question :
namespace MyFeatureReceiver
{
public class MyFeatureReceiver : SPFeatureReceiver
{
public override void FeatureUpgrading(SPFeatureReceiverProperties properties, String upgradeActionName, IDictionary<String, String> parameters)
{
SPSite site = properties.Feature.Parent as SPSite;
switch (upgradeActionName)
{
case "UpgradeTo1001":
AddCustomCodeTo1001(site);
break;
}
}
private void AddCustomCodeTo1001(SPSite site)
{
using (SPWeb rootWeb = site.RootWeb)
{
// Actions personnalisées
}
}
}
II – Mise en place de l’upgrade avec Visual Studio pour la feature de WebPart
Maintenant, si je souhaite rajouter une nouvelle WebPart (BizTalkViewerWebPart), je commence par la rajouter dans ma solution.
Ensuite dans le « Site.WebParts.Template.xml », il me suffit de mettre en place une structure similaire à celle-ci :
<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/" Version="1.0.0.1">
<UpgradeActions>
<VersionRange BeginVersion="1.0.0.0" EndVersion="1.0.1.0">
<ApplyElementManifests>
<ElementManifest Location="BizTalkWebPart\Elements.xml" />
</ApplyElementManifests>
</VersionRange>
</UpgradeActions>
</Feature>
Après il me reste plus qu’à déployer ma solution, puis de réaliser la mise à niveau sur mon site. Au passage un projet intéressant pour consulter l’ensemble des mises à jour disponible pour un site : http://spfeatureupgrade.codeplex.com/
Pour mettre à niveau mon site, powershell peut aussi faire le travail :
$site = Get-SPSite(“http://monsite/”)
$site.Features[“ID”].Upgrade($false) ($false permettant de réaliser l’upgrade que si cela est nécessaire)
En espérant que ça vous apporte un peu de lumière sur le mécanisme de mise à niveau des features avec SharePoint et Visual Studio.
