Les Features sont la pierre angulaire de pratiquement tous nos développements SharePoint pour en contrôler le déploiement et le retrait. Parfois, on veut pouvoir interdire leur activation si des contraintes ne sont pas satisfaites et on peut y arriver nativement avec les dépendances de Features.
Mais que peut-on faire si on souhaite gérer plus finement l’activation de nos Features pour interdire l’activation si certaines conditions ne sont pas respectées ?
Il m’est arrivé de vouloir interdire l’activation de 2 Features pour les rendre mutuellement exclusives en affichant un message d’erreur indiquant à l’utilisateur explicitement ce qui ne va pas. Un petit tour sur le net m’a permis de trouver différentes techniques pour gérer l’activation grâce, notamment, à un Feature Receiver et sa méthode FeatureActivated dans lequel on utilise un SPLongOperation qui navigue vers une page d’erreur, le cas échéant.
Ce genre de technique pose, néanmoins, 2 problèmes :
- Dès le début de l’appel de cette méthode, la Feature est déjà considérée comme activée et donc, il faut gérer son retrait (en quelque sorte un retour arrière) si on choisit d’afficher une erreur.
- Ca ne marche pas avec PowerShell/Visual Studio ! En effet, il n’y a pas toujours de contexte Web…
Si on retourne vers une approche plus .NET, on peut essayer de lancer une exception avec un message en paramètre :
La Feature n’a bel et bien pas été activée mais le message retourné n’est pas ce qu’on a demandé.
Voyons ce qui se passe si on lance une SPException à la place :
On obtient le bon message d’erreur qui est affiché tant dans une console que dans le navigateur !
On est encore loin du must qui serait avoir des activations variabilisées au runtime de nos Features mais on peut au moins les empêcher de s’activer n’importe comment avec quelques SPException bien placées.
Pierrick
