Introduction

Dans la partie précédente nous avons vu ce qu'étais un Service Application, ses avantages, ses inconvénients. Le principal inconvénient et la lourdeur de développement dans le sens où il faut tout faire (comme à la belle époque où les générateurs de code étaient peu présentsJ). Cependant le fait qu'il n'y ait pas de génération de code est relativement normal car chaque service est très différent dans son implémentation et dans son architecture. SharePoint permet de brancher des Services Applications un peu comme des plugins, ce qui permet au service de s'appuyer sur l'architecture de SharePoint.

Comme rien n'est prévu à la base pour faire un service application, bien entendu le type de projet service application n'existe pas dans Visual Studio. La première chose à faire est donc de créer le projet a partir d'un projet vide SharePoint et de monter de toute pièce les références, les répertoires, les features. Dans tous les cas cela reste plus simple qu'un développement pour SharePoint 2007 sous Visual Studio 2005 ou 2008.

Création du projet SharePoint Service Application

Comme le type de projet n'existe pas on va commencer par s'appuyer sur un projet vide SharePoint.

On commence par créer un projet SharePoint vide :

Le déploiement sera du style Farm Solution, en effet, les Sand Box solution par définition empêchent l'accès au API d'administration ce qui est essentiel pour les Services Applications car ils s'installent dans l'administration centrale de SharePoint.

Puis on ajoute les références à « System.Configuration.dll », « System.Management.dll » et « System.Web.dll ». Ces références sont très simples à installer car elles font partie du cache Visual Studio et apparaissent donc directement dans l'onglet .Net de l'écran des références.

On va ajouter deux autres références qui ne sont pas aussi simple que les références .Net que l'on vient d'ajouter.

Ces deux références sont « System.Management.Automation.dll » et « Microsoft.SharePoint.PowerShell.dll ».
La première se trouve avec le Windows SDK dans « c:\Program Files\Reference Assemblies\Microsoft\WindowsProwershell\v1.0 ».

Si vous n'avez pas le Windows SDK, la dll se trouve dans le GAC, mais pas dans le cache de Visual Studio, cela nécessite donc de l'extraire du GAC et de la copier dans un répertoire accessible facilement par Visual Studio.

Pour la récupérer il suffit de taper dans une command DOS en mode administrateur :

C:\>xcopy c:\Windows\assembly\GAC_MSIL\System.Management.Automation\1.0.0.0__31bf3856ad364e35\System.Management.Automation.dll c:\temp\

Et vous retrouvez la DLL dans le répertoire Temp de votre ordinateur.

Ensuite il suffit de faire une référence dessus.

Pour la DLL Microsoft.SharePoint.PowerShell.dll c'est identique on la récupère dans le GAC avec la commande suivante :

C:\>xcopy c:\Windows\assembly\GAC_MSIL\Microsoft.SharePoint.PowerShell\14.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.Powershell.dll c:\temp\

Et on retrouve la DLL dans le répertoire Temp de notre ordinateur.

Pour plus d'information sur la façon d'extraire une DLL depuis le GAC je vous conseille la lecture de ce poste en anglais :

http://metahat.blogspot.com/2008/08/copy-extract-dll-from-gac.html

L'autre possibilité encore plus simple est d'éditer le fichier csproj avec le bloc note est ajouter les deux lignes suivante dans la section <ItemGroup> :

<Reference Include="System.Management.Automation"/>
<Reference Include="Microsoft.SharePoint.Powershell"/>

Ensuite on va jouter la feature pour le service application:

On renomme notre feature et on change le scope en Farm :

Maintenant on va paramétrer les répertoires de déploiement des fichiers. Pour cela on va ajouter les SharePoint Mapped Folder (clic droit sur le projet SharePoint)

On va mapper les répertoires suivant :

{SharePointRoot}\TEMPLATE\ADMIN

{SharePointRoot}\CONFIG\POWERSHELL\REGISTRATION

{SharePointRoot}\WebClient

{SharePointRoot}\WebServices

Maintenant on va créer des répertoires AdventureWorksServiceApplication comme répertoire enfant de; Admin, WebClient et WebServices ; afin de différencier les fichiers de notre solution des fichiers Standard de SharePoint. Pour le répertoire « registration » les fichiers doivent être à la racine.

Voici a quoi doit ressembler votre projet :

Il nous reste une dernière chose à faire est notre projet est prêt.

Lorsqu'on travaille avec un projet SharePoint on a un token qui permet de mettre la signature complète de la DLL en remplacement de ce token pendant la compilation, mettre la signature complète d'une dll peut être rébarbatif on utilise donc naturellement ce token. Hors ce token marche pour toutes les extensions dont on va se servir sauf SVC. On va donc « enseigner » au projet qu'il doit le faire pour SVC.

Pour cela on édite à nouveau le ficher .csproj avec le bloc note et on ajoute la ligne suivante en dessous d'un autre PropertyGroup :

<PropertyGroup>
<TokenRemplacementFileExtensions>svc</TokenRemplacementFileExtensions>
</PropertyGroup>

Pour plus d'information sur les token je vous conseille la lecture de ce poste :

http://www.chaholl.com/archive/2010/03/10/how-deploy-a-wcf-service-to-sharepoint-2010.aspx

Voilà notre projet pour les Services Application est prêt maintenant on va s'occuper du projet pour le client.

Création du projet SharePoint Service Application Consumer

Comme pour le projet du service on va partir d'une modèle de projet (Empty SharePoint Project).

On va sélectionner le type de Déploiement en tant que Farm, il est assez rare d'avoir des clients de Service Application spécifiques pour un site.

On ajoute les mêmes références que pour le service à savoir :

• System.Configuration
• System.Management
• System.Web
• System.Management.Automation
• Microsoft.SharePoint.PowerShell

On choisira la technique qui nous semble judicieuse parmi les trois techniques expliquées plus haut.

On ajoute aussi une référence au projet de la Service Application :

Voilà pour l'instant a part la nouvelle référence on est proche de ce qui a été mis en place plus haut.

Comme « Mapped Folder », les choses sont différentes, dans le sens ou on n'a pas besoin de toutes l'architecture qu'on a mis pour le service application, on va juste mettre {SharePointRoot}\CONFIG\POWERSHELL\REGISTRATION.

Voici à quoi devrait ressembler votre projet au final:

Conclusion

Notre projet est prêt l'idéal serait de l'enregistrer en tant que template comme cela si on en a encore besoin par la suite (on sait jamais dès fois que vous développeriez des centaines de services applications).

Maintenant que notre structure de projet est faite on est au point de départ. Tout est à faire concernant le service application.

Dans la prochaine partie on verra comment mettre en place le service qui est le point central du service application.

Pour aller plus loin

http://metahat.blogspot.com/2008/08/copy-extract-dll-from-gac.html

http://www.chaholl.com/archive/2010/03/10/how-deploy-a-wcf-service-to-sharepoint-2010.aspx