Les solutions sont des composants SharePoint que l'on va utiliser pour gérer et déployer nos composants de manière centralisée et totalement automatisée.

Dans de précédents articles (déploiement de webparts avec Visual Studio 2008, Travail avec les Features, Création de webparts verbs, etc.…), je vous ai montré comment effectuer un déploiement " manuel ", disons plutôt semi-automatisé, à l'aide de Visual Studio.

Ce type de déploiement est très performant lorsque nous sommes en phase de tests, car il permet de déployer rapidement nos composants, et ceci en demandant à Visual Studio d'automatiser le processus.

Malheureusement, lorsque l'on passe dans une phase de livraison, ce type de déploiement est totalement inadapté, et sera remplacé par les solutions.

L'objectif de cet article est donc de présenter les solutions, et de montrer la simplicité avec laquelle l'on va pouvoir gérer tous nos composants déployés.

Dans cet article, nous allons mettre en œuvre un déploiement de Features via les solutions. Nous verrons également comment rajouter des language packs à une solution déployée.

I. Tour d'horizon

A partir de l'administration centrale, nous allons pouvoir gérer nos solutions.

Image non disponible

Mais avant de pouvoir les gérer, nous allons les créer et les déployer.

Pour l'instant, si nous cliquons dessus, nous avons juste accès à un message nous signalant qu'aucune solution n'a encore été déployée.

Image non disponible

II. Création d'un solution package

Un solution package est un fichier cab compressé et renommé en .wsp, et qui va contenir les composants à déployer sur notre serveur.

Ces composants peuvent être des Features, des WebParts, des Sites Definitions, bref tous les composants SharePoint sont déployables via les solutions ; même des entrées du fichier web.config et des politiques de CAS (Code Access Security) le sont !

En plus des composants à déployer, un solution package va également contenir 2 fichiers :

  • Un fichier Manifest.xml, qui va nous permettre de définir les différents composants que nous allons déployer,
  • Un fichier portant l'extension .ddf, qui va nous servir à définir la structure et de notre fichier solution .wsp (et du fichier cab correspondant !) ; ce fichier .ddf sera ensuite utilisé par l'outil makecab pour générer notre solution.



Dans le cadre de cet article, nous allons partir du projet qui a été réalisé durant l'article sur les Features, et nous allons donc passer par les solutions pour déployer nos Features au sein de notre ferme.

Nous allons donc reprendre le projet qui a été réalisé durant cet article et rajouter un nouveau dossier que nous allons appeler " Solution ", et qui va nous servir à héberger tous les fichiers nécessaires à notre solution.

Image non disponible

II-A. Création du Manifest.xml

C'est ce fichier qui va contenir les métadonnées de notre solution.

En effet, c'est dans ce fichier que nous allons définir tous les composants à déployer.

Dans ce fichier, nous allons par exemple pourvoir spécifier à SharePoint, d'installer des Features, de déployer des assemblies dans le GAC ou le répertoire bin de l'application web, ou encore d'ajouter des entrées Safe Controls. Ce fichier va donc principalement être utilisé pour déterminer les différentes actions à effectuer.

Pour savoir comment bénéficier de l'auto complétion avec Visual Studio en éditant ce type de fichier, rendez-vous sur ce postAutocomplétion pour CAML dans Visual Studio.

Dans notre cas, nous allons déployer uniquement nos Features, et donc nous n'utiliserons que les nœuds nécessaires.

L'installation de nos Features va nécessiter aussi :

  • Une assembly dans le GAC
  • Des master pages
  • Des fichiers XML.



Dans ce fichier, nous avons donc spécifié " tous " nos composants, chacun à sa place.

L'élément FeatureManifests va nous permettre de lister toutes nos Features dans chacun de ses nœuds enfants FeatureManifest.

Et enfin, l'élément Assemblies va nous permettre de lister toutes nos assembly, et leur cible (GAC ou bin de l'application web).

Nous allons à présent passer à la création du fichier ddf

II-B. Création du fichier ddf

Le fichier .ddf va nous permettre d'indiquer à notre solution package où se trouvent les composants à déployer sur notre serveur source, et ou nous souhaitons déployer ces composants sur les serveurs cibles. Ce fichier va donc principalement être utilisé par SharePoint pour retrouver les informations de copie des différents composants.

On peut découper ce fichier en 2 parties.

Une partie que l'on qualifierait de " statique ".

.OPTION EXPLICIT
.Set CabinetNameTemplate=Coforcert.Features.Demo.wsp
.set DiskDirectoryTemplate=CDROM
.Set CompressionType=MSZIP
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package



Cette partie peut être qualifiée de statique, car, à l'exception du nom de notre solution (ici surligné en jaune), elle n'est pas directement liée aux composants de notre projet, et on pourrait même se contenter de l'utiliser tel quel sur d'autres projet.

On aura également une 2ème partie, ici qualifiée de " dynamique ", car c'est elle qui va changer au fur et à mesure des projets, et s'adapter à nos composants.


Solution\manifest.xml manifest.xml
TEMPLATE\FEATURES\Coforcert_ApplyInternetMP\feature.xml Coforcert_ApplyInternetMP\feature.xml
TEMPLATE\FEATURES\Coforcert_ApplyInternetMP\ManageFeature.xml Coforcert_ApplyInternetMP\ManageFeature.xml
TEMPLATE\FEATURES\Coforcert_MasterPages\feature.xml Coforcert_MasterPages\feature.xml
TEMPLATE\FEATURES\Coforcert_MasterPages\elements.xml Coforcert_MasterPages\elements.xml
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcert.master Coforcert_MasterPages\masterpages\coforcert.master
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcertinter.master Coforcert_MasterPages\masterpages\coforcertinter.master
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcertintra.master Coforcert_MasterPages\masterpages\coforcertintra.master
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcertextra.master Coforcert_MasterPages\masterpages\coforcertextra.master
bin\Debug\Project.dll Project.dll



C'est donc dans cette partie que nous avons listé tous nos composants, avec dans la partie de gauche, leur emplacement actuel, et dans celle de droite, leur emplacement sur le serveur cible.

Ci-dessous, le code du fichier final, intitulé "Cab.ddf".


.OPTION EXPLICIT
.Set CabinetNameTemplate=Coforcert.Features.Demo.wsp
.set DiskDirectoryTemplate=CDROM
.Set CompressionType=MSZIP
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package


Solution\manifest.xml manifest.xml
TEMPLATE\FEATURES\Coforcert_ApplyInternetMP\feature.xml Coforcert_ApplyInternetMP\feature.xml
TEMPLATE\FEATURES\Coforcert_ApplyInternetMP\ManageFeature.xml Coforcert_ApplyInternetMP\ManageFeature.xml
TEMPLATE\FEATURES\Coforcert_MasterPages\feature.xml Coforcert_MasterPages\feature.xml
TEMPLATE\FEATURES\Coforcert_MasterPages\elements.xml Coforcert_MasterPages\elements.xml
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcert.master Coforcert_MasterPages\masterpages\coforcert.master
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcertinter.master Coforcert_MasterPages\masterpages\coforcertinter.master
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcertintra.master Coforcert_MasterPages\masterpages\coforcertintra.master
TEMPLATE\FEATURES\Coforcert_MasterPages\masterpages\coforcertextra.master Coforcert_MasterPages\masterpages\coforcertextra.master
bin\Debug\Project.dll Project.dll



Voici ou nous en sommes.

Image non disponible



A cette étape, si nous avions bien fait les choses lors de notre projet initial concernant les Features, nous aurions déjà pu déployer notre solution.

Si vous vous souvenez, lorsque nous avons réalisé le projet sur les Features, nous avons utilisé des fichiers de ressources localisés (*.fr-fr.resx); de même, tout à l'heure, je vous ai dit que nous avions listé " tous " nos composants, tous sauf les fichiers de ressources localisés.

En effet, le but d'une solution est de pouvoir être déployés de manière globale au sein de votre ferme, or si nous y incluons directement des ressources spécifiques à une langue, leur intérêt devient limité ; d'autant plus qu'avec les variantes, SharePoint est capable de gérer des sites " synchronisés ", mais avec des langues différentes.

Pour résoudre ce problème (qui n'en est pas un !), les solutions sont capables de gérer des packs de langues additionnels ; ce sont ces packs de langues qui vont servir à déployer des ressources localisées.

Pour en revenir à notre cas, étant donné que nous n'avons pas défini de fichier de ressources global, nous allons devoir déployer, en même temps que la solution, notre pack de langue.

II-C. Création du pack de langue fr-fr



La création du pack de langue se déroule de la même façon que la création de la solution ; nous allons à nouveau devoir créer un Manifest.xml et un fichier ddf.

Pour plus de convivialité, nous allons leur donner un nom qui indiquera leur langue ; ainsi notre nouveau fichier manifest.xml, nous allons l'appeler manifest.fr-fr.xml, et notre fichier cab.ddf, nous allons l'appeler cab.fr-fr.ddf.

Les packs de langue présente quand même des spécificités par rapport aux solutions :

  • 1. Le fichier Manifest.xml du pack de langues doit porter le même ID que la solution à laquelle le pack est rattaché,
  • 2. Le nom de la solution, utilisé dans le fichier ddf pour renseigner le paramètre CabinetNameTemplate, doit également être le même que celui de la solution.





Et celui du fichier Cab.fr-fr.ddf


.OPTION EXPLICIT
.Set CabinetNameTemplate=Coforcert.Features.Demo.wsp
.set DiskDirectoryTemplate=CDROM
.Set CompressionType=MSZIP
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package


Solution\manifest.fr-FR.xml manifest.xml
RESOURCES\Coforcert_MasterPages.fr-fr.resx RESOURCES\Coforcert_MasterPages.fr-fr.resx
RESOURCES\Coforcert_ApplyInternetMP.fr-fr.resx RESOURCES\Coforcert_ApplyInternetMP.fr-fr.resx



Plusieurs choses à remarquer.

Tout d'abord dans le fichier Manifest.fr-fr.xml, on va cette fois-ci utiliser le nœud RootFiles et ses nœuds enfant RootFile pour rajouter nos fichiers de Ressources.

Ce nœud RootFiles spécifie qu'on se trouve à la racine du répertoire 12. C'est donc la raison pour laquelle dans location, on va préciser " Resources\nom_Ressources.resx ", car nous souhaitons déployer nos fichiers de ressources dans le dossier de ressources partagées, accessible situé à 12\Resources.

Je vois venir votre question : " Pourquoi n'avons-nous pas utilisé l'élément TemplateFile ? "

Pour la simple et bonne raison que l'élément TemplateFiles pointe sur le répertoire 12\Template, et ne nous permet donc que de déployer des fichiers dans le dossier Template (Features, ControlTemplate, etc.…) ; et étant donné que le dossier " Resources " se trouve au même niveau dans l'arborescence que le dossier Template, il nous est inaccessible depuis l'élément TemplateFile.

De même, si vous regardez de près le schéma du manifest.xml, vous verrez également les éléments " Resources " et " ResourceFile " ; ces éléments vont nous permettre de déployer des ressources privées à la Feature directement dans le dossier de la Feature, comme c'est le cas pour les Features ayant trait au workflow (regardez par exemple dans le dossier représentant la Feature " OffWFCommon ", vous y verrez un dossier Resources), et sont donc inadaptés encore une fois au déploiement d'une ressource partagée.

Pour terminer avec les ressources, on a également les éléments ApplicationResourceFiles et ApplicationResourceFile qui vont nous servir à déployer des ressources disponibles pour l'application web.

Voici donc où nous en sommes

Image non disponible



A présent, nous allons pouvoir générer notre solution.

III. Création et déploiement de notre solution package



Nous allons utiliser les utilitaires MakeCab et STSADM pour créer notre solution et la déployer dans notre ferme.

Le déploiement va s'effectuer en 2 étapes :

  • 1) L'installation, phase durant laquelle SharePoint copie le fichier wsp dans la base de données de configuration, aussi appelé le solution store.
  • 2) Le déploiement à proprement parlé, phase durant laquelle SharePoint crée un Timer Job qui est exécuté par tous les serveurs web de la ferme.



Dans notre exemple, nous allons créer un Timer Job qui va se charger de déployer immédiatement notre solution ; cependant, dans un environnement de production, il est préférable de planifier les déploiement durant une période ou vous n'avez pas d'utilisateur connecté sur vos sites SharePoint, car par défaut, en fin d'installation, la commande " IISRESET " est appelée et redémarre donc les services IIS.

Afin de " factoriser " nos déploiement, plutôt que de passer par la ligne de commande, nous allons encore une fois créer un fichier bat, fichier que nous allons nommer " deploy.bat ".

Dans ce fichier, nous allons y insérer les commandes suivantes

; makecab /f Solution\Cab.ddf

@SET SPDIR="c:\program files\fichiers communs\microsoft shared\web server extensions\12"

%SPDIR%\bin\stsadm -o addsolution -filename Package\Coforcert.Features.Demo.wsp %SPDIR%\bin\stsadm -o execadmsvcjobs

%SPDIR%\bin\stsadm -o deploysolution -name Coforcert.Features.Demo.wsp -immediate -allowgacdeployment -force %SPDIR%\bin\stsadm -o execadmsvcjobs

makecab /f Solution\Cab.fr-FR.ddf

%SPDIR%\bin\stsadm -o addsolution -filename Package\Coforcert.Features.Demo.wsp -lcid 1036 %SPDIR%\bin\stsadm -o execadmsvcjobs

%SPDIR%\bin\stsadm -o deploysolution -name Coforcert.Features.Demo.wsp -immediate -force -lcid 1036 %SPDIR%\bin\stsadm -o execadmsvcjobs

@ECHO "Déploiement de la solution terminé !"



Ici nous créons donc nos solutions à partir de nos 2 fichiers cab, l'un pour la solution, et l'autre pour le pack de langue français ; ensuite, nous installons la solution dans le solution store, nous faisons de même avec le pack de langue, puis nous déployons notre solution.

Compte tenu que nous devons déployer une assembly dans le GAC, il nous faudra préciser le paramètre allowGacDeployment lors du déploiement.

De même, pour annuler le déploiement de notre solution, nous devons d'abord la retirer via l'option retractsolution, et ensuite exécuter l'option deletesolution.

Tout comme nous avons d'abord ajouter la solution avant d'ajouter tout pack de langue, puis déployer la solution avant de déployer tout pack de langue, nous allons d'abord devoir retirer tous les packs de langue avant de retirer la solution, et également supprimer tous les packs de langues avant de pouvoir supprimer la solution.

Voici donc où nous en sommes

Image non disponible



Maintenant, nous avons tout simplement à exécuter le fichier deploy.bat pour installer notre solution et déployer tous nos composants.

Ici, nous allons encore une fois passer par Visual studio pour automatiser la tache.

Pour le cela, dans les propriétés du projet, nous allons lui spécifier d'exécuter le fichier deploy.bat.

Image non disponible



Il ne nous reste plus qu'à compiler notre projet avec Visual Studio. Vous pouvez regarder la sortie de Visual Studio en choisissant d'afficher la fenêtre Output, dans le menu View de Visual Studio.

Une fois le déploiement terminé, nous allons le vérifier via la page Opérations de l'administration Centrale, en cliquant sur le bouton Gestion des Solution.

Voici ce que nous devrions obtenir

Image non disponible



De plus, en cliquant sur chacun des liens, nous obtenons des détails supplémentaires

Image non disponible
Image non disponible



Maintenant, allons vérifier que tous nos composants ont bien été déployés ; de mon coté, je retrouve

  • Les 2 fichiers de ressources déployés dans le répertoire 12\Resources
  • Les 2 dossiers correspondant à mes Features
  • L'assembly déployée dans le GAC.



Nos Features sont également disponibles, et les informations de langues sont bien récupérées.

Image non disponible



De même, si je supprime ma solution, tous ces composants disparaissent !

Idéal pour gérer les mises en production !

Plus besoin de regarder à droite à gauche si il reste de composants par ci et par la ; non ! Tout est déposé et retiré via les solutions.

Comme le dis GatGatWeb, il faut voir les solutions comme des MSI pour SharePoint !

Une fois notre solution déployée, on peut éprouver le besoin de rajouter de nouveaux pack de langues ; en effet, nous pouvons facilement imaginer qu'une entreprise s'implantant à l'international ait besoin d'avoir des sites dispensant de même fonctionnalités dans des langues diverses.

Nous allons donc voir comment rajouter des packs de langues une fois notre solution déployée.

VI. Création et installation d'un pack de langue additionnel



Pour ajouter des packs de langue une fois notre solution déployée, il nous faudra à nouveau respecter les 2 contraintes dont on avait déjà parlé, à savoir que le pack de langue doit avoir le meme identifiant de solution et le meme nom que notre solution.

Ensuite, le déploiement reste le meme.

Dans notre cas, nous allons simuler le déploiement d'un pack de langue américain. Pour faire simple, nous allons reprendre nos fichiers ressources en fr-FR et le changer en en-US, de manière à obtenir " Coforcert_ApplyInternetMP.en-US.resx " et " Coforcert_MasterPages.en-us.resx ".




;
.OPTION EXPLICIT
.Set CabinetNameTemplate==Coforcert.Features.Demo.wsp
.set DiskDirectoryTemplate=CDROM
.Set CompressionType=MSZIP
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package


Solution\manifest.en-us.xml manifest.xml
RESOURCES\Coforcert_MasterPages.en-us.resx RESOURCES\Coforcert_MasterPages.en-us.resx
RESOURCES\Coforcert_ApplyInternetMP.en-us.resx RESOURCES\Coforcert_ApplyInternetMP.en-us.resx



Comme vous pouvez le constater, seules les extensions langues différes.

Voici le projet final sous visual studio.

Image non disponible



Pour lancer l'installation de ce pack de langue, nous allons à nouveau créer un fichier bat de déploiement que l'on va appeler DeployLP.bat ; voici son code

makecab /f Solution\cab.en-us.ddf

@SET SPDIR="c:\program files\fichiers communs\microsoft shared\web server extensions\12"

%SPDIR%\bin\stsadm -o addsolution -filename PACKAGE\Coforcert_Features.wsp -lcid 1033 %SPDIR%\bin\stsadm -o execadmsvcjobs

%SPDIR%\bin\stsadm -o deploysolution -name Coforcert_Features.wsp -immediate -force -lcid 1033 %SPDIR%\bin\stsadm -o execadmsvcjobs

@ECHO "Déploiement de la solution terminé !"



Une fois celui-ci exécuté, nous obtenons la validation sur l'interface web.

Image non disponible



Notre solution a maintenant 2 pack de langues, la version française et la version anglaise.

V. Conclusion



Nous venons de voir dans cet article comment travailler avec les solutions, et quels en étaient les intérêts.

Nous avons également appris à les mettre en œuvre, les installer, les supprimer et rajouter des packs de langue.

Dorénavant, pour vos livraisons SharePoint, vous n'aurez plus d'excuses !