Développement d’applications SharePoint (1/6)

Comme vous le savez tous, SharePoint (je parle de SharePoint dans son ensemble, que cela soit WSS 3.0 ou MOSS 2007) peut être installé uniquement sur un serveur (Windows Server 2003 & 2008). [Note : Bamboo Solutions propose un guide et un exécutable permettant d’installer WSS 3.0 sur Windows Vista SP1, mais cela ne sera pas traité dans cet article.]
Ainsi, pour développer sous SharePoint, nous avons deux alternatives :

• installer Windows Server 2003/2008 sur notre machine, et installer également tous les outils de développement (Visual Studio et tous les utilitaires indispensables, comme .NET Reflector ou CAML Builder). Cette solution peut poser des problèmes de réactivité générale de la machine, mais également au niveau de la gestion d’énergie dans le cas de portables. Je ne parle pas des licences …


• L’autre alternative consiste à utiliser une machine virtuelle que l’on lancera depuis notre station de travail.

Cette dernière approche est de loin la plus conseillée, malgré les recommandations matérielles préconisées élevées. En effet, une machine virtuelle hébergeant WSS 3.0 doit au moins avoir 1 giga de RAM (compter plus avec Visual Studio), ce qui veut dire que la machine physique doit être assez puissante. De plus, travailler dans un environnement virtuel amène également son lot de problèmes : lenteur de la souris à certains moments, copier / coller récalcitrant, problématiques réseau etc.…

Cependant, il existe une autre méthode, que je qualifierais « d’extrême » : celle de développer directement depuis une station de travail classique (Windows XP/Vista).

Il faudra au préalable rapatrier toutes les dll SharePoint sur la machine pour pouvoir les ajouter en référence dans nos projets Visual Studio (la plupart des dll SharePoint se trouvent dans le répertoire « 12\ISAPI », les autres seront dans le GAC). Une fois le code compilé, il faudra copier tous les fichiers liés à la fonctionnalité développée (dll, xml, gif ….) sur le serveur SharePoint.

Pour être plus carré et respectueux des « bonnes pratiques », on pourra générer une solution SharePoint (package wsp), la copier sur un des serveurs de la ferme SharePoint et utiliser stsadm pour installer la solution, puis la déployer. Il faut avoir accès en terminal service sur le serveur pour exécuter stsadm (dans l’hypothèse ou la plateforme SharePoint n’est pas une machine virtuelle en local sur la station de travail). Mais le plus gros problème de cette approche réside dans le fait qu’il n’est pas possible de déboguer son code.

Dans cet article, je vous propose une solution à mettre en place, vous offrant le meilleur des deux mondes: la flexibilité et la performance du développement depuis une station de travail tout en préservant la possibilité de déboguer son code.

Dans un premier temps nous verrons comment déployer son code simplement sur une plateforme SharePoint depuis sa station de travail.

Nous verrons ensuite comment déboguer son code (que notre plateforme SharePoint soit un serveur physique ou virtuel en local, ou que notre plateforme soit dans un autre domaine ou non).

Pour finir, nous automatiserons la pluparts de ces tâches pour améliorer encore plus l’expérience développeur.