Ce billet fait suite au précédent sur les outils de création et de déploiement dans SharePoint où j'ai déjà présenter deux outils avec leurs avantages et inconvénient :
Maintenant, je vais vous parler d'autres outils :
Pour ceux qui ne connaîtraient pas CodeRush (ou Refactor! Pro), il s'agit d'un Addins à Visual Studio 2005/08 développé par DevExpress. Le but de ces outils étant d'améliorer la productivité des développeurs en automatisant certaines tâches (renommage, factorisation, etc...).
Avant de commencer, je tiens à préciser que je ne rentrerai pas dans le débat du "meilleur outil " et je me concentrerai uniquement sur ces extensions de CodeRush pour SharePoint développé par Andrew Connell.
Pour information, sachez simplement que CodeRush & Refactor! Pro ne sont pas gratuits (environ 250$) mais que l'addin SharePoint codé par Andrew est totalement gratuit. Voici une petite démo de CodeRush et Refactor! Pro.
Bon, vous avez saisi l'idée : CodeRush & Refactor! Pro sont censés vous faire coder plus vite. Or nous savons tous que le développement SharePoint n'est pas si commun que ça au développement C# classique (Utilisation de GUID, création de fichier XML, Event receiver, etc ...), alors en quoi, ces outils de développement générique peuvent nous aider ?
En effet, si je prend l'exemple d'une webpart de type "Hello World":
- HelloWorld.cs (Fonctionnement de la webpart)
- HelloWorld.webpart (Fichier Descriptif)
- Feature.xml (Description de la feature)
- Elements.xml (Upload du Fichier WebPart)
- Etc ...
Le seul fichier auquel vous apportez une réelle plus-value est HelloWorld.cs, tout le reste n'est que plomberie nécessaire à SharePoint. C'est ce raisonnement qui a pousser Andrew Connell à développer ces extensions. Voyons ce que ça a donné :
Création de GUIDS :
Si vous non plus, n'aimez pas faire : Tools >> Create GUID >> New >> Copier >> Coller >> Supprimer les accolades (si besoin)... Andrew vous propose de tapper directement dans votre fichier XML : newguid [espace]
Simple mais bien pratique en tout cas !
Création des fichiers feature.xml :
Je vous entend déjà me dire : "Ça existe déjà dans VseWss, WSPBuilder Extensions, STSDEV, etc..." Personnellement, j'apprécie le petit plus qu'est la navigation avec la touche [ENTREE] et une description lors du survol d'un élément.
Pour en bénéficier, tapez : fxml[espace] puis [entrée] pour passer d'un élémént à un autre.
Création de fichiers feature.xml avec gestion des Features Receivers :
Même système que précédemment mais avec en plus la détection automatique de l'utilisation de SPFeatureReceiver dans votre projet et de l'ajout de la DLL générée (Full Name) dans le champ du fichier feature.xml. Le tout fait automatiquement sans passer par le non moins fabuleux outil de Lutz's Reflector pour récupérer le nom complet.
Et encore bien d'autres fonctionnalités que vous pourrez retrouver à ces adresses :
A noter que Andrew à mis à jour récemment ces extensions. Vous trouverez plus d'informations sur ce post : AC's CR/R tools for SPDevs Updated: v1.1
Pour finir, j'aime beaucoup cet outil qui me laisse avoir une grande liberté dans la création et la composition de mes projets SharePoint tout en m'apportant le petit plus, qui fait toute la différence en terme d'intégration.
Le moins que l'on puise dire est que Carsten Keutmann (créateur de WSPBuilder et de SharePoint Manager) aura été utile à la communauté SharePoint en 2007 !
En créant et améliorant tout à long de l'année WSPBuilder, Carsten aura résolu à lui seul une des plus grandes problématiques qu'un développeur SharePoint peut rencontrer lors d'une mission : Le packaging d'un projet SharePoint en un fichier wsp.
Pour illustrer mes propos, reprenons l'exemple de la webpart HelloWorld :
Utiliser une feature pour déployer la webpart dans SharePoint est une bonne habitude à prendre qui vous permettra d'activer la fonctionnalité simplement sur vos sites SharePoint.
Mais si vous voulez déployez votre webpart, il va falloir déployer la DLL (dans le GAC ou dans le BIN) ainsi que les fichiers XML (dans le repertoire Features) de chacun de vos WebFronts.
Pour un peu que vous en ayez plusieurs et que vous rajoutiez à votre webpart ou à votre feature quelques images, css, etc... Le déploiement se révélera vite très compliqué.
Mais pas de panique, l'équipe SharePoint a pensé à tout et vous permet de rassembler tout les composants que vous avez besoin en un seul fichier et de les déployer automatiquement via l'utilisation d'un package appelé "Solution", ayant communément une extension de fichier en .wsp.
Pour générer ce fichier, vous aller avoir besoin de créer deux fichiers :
C'est ce fichier qui va décrire à SharePoint ce qu'il doit faire des autres fichiers présents dans la solution. Le fichier "solution" n'est en fait qu'un fichier .cab renommé en .wsp qui référence les fichiers présents dans le fichier .ddf
- makecab.ddf (le nom du fichier n'est pas important)
Bref, cela peut se révéler assez compliqué de créer tout ça à la main quand on commence à avoir un peu plus de fichiers...
Pour plus de détails, je vous encourage à lire cet excellent article de Ted Pattison sur la création d'un package SharePoint : Creating a Solution Package in Windows SharePoint Services 3.0
Vous l'aurez sans doute compris, c'est au niveau de la phase de création des fichiers DDF, XMl, et WSP que WSPBuilder intervient. Il suffit de lui préciser où vous souhaitez déployer vos fichiers (GAC, BIN, 12\Templates\Features, etc...) :
Il ne vous reste plus qu'a lancer l'utilitaire WSPBuilder.exe via une ligne de commande ...
... pour qu'il vous génère automatiquement le fichier WSP qui vous intéresse :
Il ne vous restera plus qu'à le déployer sur votre environnement SharePoint (stsadm -o addsolution, déploysolution, activatefeature, etc..) et le tour est joué !
On notera que depuis peu, WSPBuilder s'intègre à Visual Studio 2005/2008 avec l'ajout d'un nouveau menu WSPBuilder dans le menu contextuel de projet :
Ce menu vous permettra de générer directement votre fichier wsp, de le déployer, de le désinstaller, de le mettre à jour, d'en faire une copie "quick and dirty" vers le repertoire 12 local et finalement de recycler les pools d'applications (ce qui est bien plus rapide qu'un IISRESET).
Mais il y a aussi l'arrivée de nouveaux templates de projets avec une arborescence de répertoires pré construite, bien pratique :
Pour résumer, WPSBuilder est devenu en quelques mois un vrai référence en terme de génération de package SharePoint. De plus il se couple très bien avec les extensions CodeRush pour SharePoint et permet de générer la solution qui vous correspond. A mes yeux, ces deux outils peuvent être une alternative tout à fait valable sur VisualStudio 2008 en attendant les VseWSS 1.2 qui devraient sortir en Juin 2008.
<Philippe/>
