Gestion des ressources, rendre vos solutions SharePoint « globally deployed »

Jan 23, 2014

clip_5F00_image002_5F00_thumb_5F00_2CB1CF09.jpg

Introduction

Cela fait quelques temps déjà que je voulais rédiger cet article, j’ai trouvé cette solution il y a quatre ou cinq mois déjà. Mais par manque de temps je n’ai pas pu le faire avant. Récemment Sébastien LEVERT, développeur SharePoint de haut vol et membre de la communauté SharePoint à Montréal, a publié un article qui traite du même genre de problématique. Allez le lire, je vais faire en sorte que nos deux articles soient complémentaires (faute d’avoir publié plus tôt) https://www.pimpmysharepoint.com/2014/01/09/deployer-des-fichiers-de-ressources-simplement/

Un peu de rappels

Si je résume rapidement, lorsque l’on développe des solutions SharePoint et qu’on veut les localiser (les rendre utilisables en plusieurs langues) on utilise des ressources .net. Ces fichiers .resx viennent de l’asp.net et sont structurés sous la forme clef/valeur. Il faut créer un fichier par langue prise en charge. Au lieu de mettre les textes directement dans notre code (ce qui est très sale de toute manière) on les référence grâce aux clefs définies.

Certaines contraintes techniques nous imposent de déployer ces fichiers à deux endroits :

  • Hive\config\resources : pour les textes utilisés dans les pages web, les contrôles utilisateurs etc.

  • Hive\Resources : pour les textes utilisés dans les workflows, timerjobs etc (ce qui est « caché » en gros)

On a par extension deux autres « emplacements » à connaitre :

  • Hive\admin\resources : resources pour le site web d’administration centrale de SharePoint.

  • App_GlobalResources : répertoire dans chacune des applications web, est une copie du hive\config\resources (copie étant effectuée via stsadm –o copyappbincontent par exemple)

Il est possible de déployer nos ressources « web » directement dans le répertoire App_GlobalResources. Cela économise un peu de travail à nos administrateurs lors du déploiement des solutions. Sébastien explique cela, mais il explique aussi une méthode pour qu’un même fichier de ressources soit déployé dans App_GlobalResources et hive\Resources. Ça permet d’utiliser de manière simple vos ressources au travers de toute votre solution (dans vos timer jobs comme au sein de vos pages applicatives par exemple). En effet on se retrouve assez rapidement dans une situation où l’on a besoin d’une ressource dans une page et dans un timerjob par exemple, nous obligeant normalement à faire des copies. C’est une bonne solution et je la recommande si vous n’avez pas la contrainte que je vais vous expliquer plus bas.

Mise en contexte

J’ai récemment participé au développement d’un produit pour SharePoint. Ce produit ajoute une nouvelle application de service à SharePoint et un nouveau service. Lors des phases de tests avant la version finale, j’ai voulu essayer quelque chose : faire tourner le service sur un serveur applicatif.

En effet c’est un cas de figure qui se présente assez souvent dès que les fermes SharePoint commencent à avoir une taille moyenne : une partie des serveurs est dédiée à la génération des pages, les web front end et l’autre à l’exécution des services gourmands, les serveurs applicatifs.

A ce moment-là nous avons été assez surpris de constater que puisque nos solutions contenaient des fichiers ressources déployés dans App_GlobalResources, elles étaient déployées uniquement sur les serveurs ayant le rôle « Microsoft SharePoint Web Foundation » activé. Du coup les dll requises pour le bon fonctionnement de notre service n’était pas présentes et ce dernier ne s’enregistrait pas correctement/ne démarrait pas.

Solution

Il fallait donc que je trouve un moyen de pouvoir utiliser des ressources au sien d’un contrôle ou d’une page sans pour autant avoir la nécessité de déployer mes fichiers dans App_GlobalResources.

La première partie de la solution m’a été apportée dans ce projet codeplex https://spexpressions.codeplex.com/ qui permet aux développeurs et/ou intégrateurs de disposer de plus de variables d’environnements SharePoint au sein des pages qu’ils conçoivent.

La solution est donc simple :

  • Une ligne dans le web.config qui indique à IIS comment interpréter une nouvelle expression

  • Une classe pour traiter cette nouvelle expression

  • Une fonctionnalité pour inscrire/enlever cette ligne du web.config

  • Les fichiers ressources déployés dans hive\Resources

Comme je suis sympa j’ai inclus un exemple dans les fichiers téléchargeables inclus à cet article.

Avantages par rapport à la solution de Sébastien :

  • Un seul fichier déployé

  • Vos solutions restent déployées de manière globale (enfin sauf si un autre élément la force à se déployer par web app)

Inconvénients :

  • Plus complexe

clip_5F00_image004_5F00_thumb_5F00_607C560B.jpg

Note: la solution que je fournis en pièce jointe est ciblée pour SharePoint 2010 mais fonctionne tout aussi bien sous 2013, notre produit est dans les deux versions.


Edité la dernière fois le 6 Sep 2021 par Vincent


Tags: