Quand la version 2007 de SharePoint est devenue disponible en 2007, la lacune principale, du point de vue du développeur, était définitivement le manque d’outils.  À cette époque, une solution, aussi complexe soit-elle, était disponible.  Vous vous rappelez lorsque vous étiez obligés de créer vos fichier .ddf à la main ? Quand vous deviez noter chacun des fichiers à développer et qu’il était immanquable que les premiers déploiements de votre solution allaient amener leurs doses de frustrations…

On a commencé à développer des outils… Majoritairement trois outils sont sortis du lot au fil des années qui ont suivies :

• Les extensions pour Visual Studio, bâties par Microsoft
• WSPBuilder
• STSDEV

Ces outils, bien que relativement utiles, ont chacun des avantages et des désavantages.  Évidemment, nous devions tous les tester.  Certains faisaient une partie du travail, tandis que d’autre ne permettaient pas tel ou tel autre truc.  J’ai fait mon choix, j’utilise celui qui me permet de faire ce que je veux, comme je le veux…

STSDEV

Quand je suis tombé sur STSDEV, on me l’a fortement conseillé pour un projet.  Cependant, j’étais relativement junior en développement SharePoint, et c’était une courbe d’apprentissage très abrupte pour un premier “vrai” projet… Par contre, c’est grâce à ce projet que j’ai compris la complexité du développement SharePoint et la puissance de l’outil STSDEV.

Cycle de développement

L’outil me permet d’avoir un cycle de développement propre, à chaque fois que je veux tester ma solution.  Quand je crée une fonctionnalité, et que celle-ci doit être modifiée dans mon environnement, je préfère de loin la méthode prescrite par Microsoft, c’est-à-dire celle où on utilise les fonctionnalités de SharePoint pour mettre à jour les solutions.  Je déteste passer “par derrière” pour faire des modifications… Je sais que SharePoint ne grognera pas, mais je suis certain qu’il est pas du tout heureux de ce que je lui fais vivre… Modifier un fichier XML directement sur le disque, ça m’horripile.  Par contre, quand j’utiliser les fonctionnalités de mise à jour d’une solution via les commandes stsadm (stsadm -o upgradesolution), je sais que je fais la bonne chose.  Peut-être que mon cycle développement est un peu plus lent à chaque fois que je dois modifier ma solution, par contre, mon cycle de développement m’assurer de la validité de mon paquetage en tout temps.  Comme mon fichier .wsp est généré à chaque compilation, je sais qu’en tout temps, j’ai une solution présentable.  Peut-être est-elle remplie de bogues.  Peut-être est-elle non fonctionnelle.  Mais je peux la déployer partout.  Et ça me plaît.

Flexibilité

J’adore comment STSDEV fonctionne… Habituellement.  Il m’arrive d’avoir des modifications au comportement à effectuer pour des raisons particulières. Par exemple, pour un projet que vous venons de terminer, nous avions à livrer des scripts qui devaient ajouter, déployer et activer les solutions ainsi que de créer une structure de collections de sites et de sites relativement complexes.  Afin de s’assurer de la validité du portail, nous exécutions souvent les scripts.  Qu’est-ce qui arrivait plus souvent qu’autrement ? Nous oubliions de récupérer nos fichiers .wsp et les inclure dans le répertoire des scripts (qui allait devenir notre livrable final). Résultat : nous exécutions les mauvaises versions des solutions.  Du temps perdu… Afin de régler le problème, puisque STSDEV est en fait seulement une série de commandes du standard Microsoft MSBuild, nous avons ajouter un simple xcopy de nos .wsp générés dans notre dossier de scripts.  Le plus gros des avantages ? Nos fichier .targets (qui incluent les inscructions MSBuild) étaient conservés dans notre gestionnaire de fichiers.  Par besoin d’avoir des instructions pré ou post compilation.  Simple, efficace, peu coûteux.

Aucune intégration à Visual Studio

L’atout majeur de STSDEV est qu’il ne demande en aucun temps une version de Visual Studio.  Puisqu’il s’agit d’une simple application console (fait en .NET et très facilement modifiable selon vos besoins…), une intégration à Visual Studio semblait complètement inutile.  Vous utilisez une version spéciale de Visual Studio ? Pas de problème ! Les solutions générées n’utilisent ni de gabarits de projets, ni de fonctionnalités ajoutées à Visual Studio.  Valide en tout temps, pour n’importe qui.  Dans un environnement où plusieurs développeurs peuvent utiliser la même solution, dans des environnements complètement différents (Visual Studio 2010, 2008, 2005), c’est un atout de taille.  Le projet reste valide.

Conseil pratique

Pour les équipes de développement qui travaillent avec un gestionnaire de source, je conseille fortement d’inclure les fichiers binaires de STSDEV à même votre solution Visual Studio.  Pourquoi ? Afin de valider que la version de STSDEV utilisé soit la même tout au long du projet !  Il sera par contre nécessaire de modifier une ligne dans les fichiers .target de vos différents projets.  Cette ligne permettra de référer à votre STSDEV qui sera relatif à votre projet, et non aux fichier binaires sur disque. Référez-y de la façon suivante :

<STSDEV>"$(SolutionDir)CHEMIN.VERS.STSDEV\stsdev.exe"</STSDEV>

Et mettez vos binaires dans un dossier à même votre solution, qui sera au même niveau que vos projets SharePoint.

Conclusion

J’utilise STSDEV, et j’en suis fier.  J’ai de la difficulté à comprendre les gens qui ne veulent pas l’utiliser.  Je comprends que les autres outils permettent aussi des choses comparables… Mais jamais avec les trois éléments clés décrits dans cet article.  Vous êtes curieux ? Je vous conseille de lui donner sa chance.  Je suis certain que vous serez facilement convaincu de l’utiliser dans la majorité de vos projets!