Ahhh, les solutions sandboxed, j’adoooore. J’interviens chez plusieurs clients qui n’ont pas un accès évident à leur ferme SharePoint, car c’est du mutualisé entre plusieurs entités du groupe, du coup, le déploiement de solution n’est pas aussi simple que sur ma machine virtuelle. En effet, il faut passer par plusieurs étapes et des fois cela est vraiment contraignent (mais justifiée, je parle juste ici de mon expérience développeur :-)). Grâce à cette nouveauté, il est possible maintenant de déployer des solutions au niveau des collections de sites, et du coup de cloisonner l’utilisation de DLL à ce niveau sans impacter le reste de la ferme.
Cependant, tous n’est pas possible : vous comprendrez bien qu’il n’est pas possible de déployer des pages dans le dossier Layouts, ou des images dans le dossier Image. L’idée étant tout de même de rester au niveau de notre collection. Il est donc tout à fait possible de développer des web parts de cette manière pour ne pouvoir les utiliser qu’au niveau de notre collection. Lors de la création du projet Visual Studio 2010, il faudra bien penser à cocher la case “Deploy as a sandboxed solution” :
Jusque là on est tout d’accord. Cependant, et j’ai eu la problématique, qu’en est-il si je veux directement utiliser cette web part dans une page que je déploie en même temps depuis ma solution SharePoint dans une bibliothèque?
J’ajoute une page ASPX à ma solution, je modifie donc le manifeste associée à ma feature pour ajouter le bout de code suivant:
1: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
2: <Module Name="MaPage">
3: <File Path="MaPage.aspx" Url="Pages/MaPage.aspx" />
4: </Module>
5: </Elements>
Ce code permet juste, à l’activation de la feature, d’envoyer la page MaPage.aspx dans la bibliothèque Pages de mon site SharePoint.
Comme ma page possède une zone de composants web parts, je peux ajouter directement à l’activation de ma feature cette web part à cette page, le code précédent devient donc :
1: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
2: <Module Name="MaPage">
3: <File Path="MaPage.aspx" Url="Pages/MaPage.aspx">
4: <AllUsersWebPart WebPartZoneID="MyWPZone" WebPartOrder="1">
5: <![CDATA[
6: <webParts>
7: <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
8: <metaData>
9: <type name="NS.WebPart1, NS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7778473ae7400000" />
10: <importErrorMessage>Error Importing</importErrorMessage>
11: </metaData>
12: <data>
13: <properties>
14: <property name="Title" type="string">WebPart1</property>
15: <property name="Description" type="string">My WebPart</property>
16: </properties>
17: </data>
18: </webPart>
19: </webParts>
20: ]]>
21: </AllUsersWebPart>
22: </File>
23: </Module>
24: </Elements>
Je spécifie le positionnement de ma web part directement dans l’XML, dans la zone nommée MyWPZone.
Déployez ce code, et tentez d’accéder à cette page. Vous obtiendrez une erreur: en effet, la DLL utilisée par la web part sera cherchée dans le GAC, or, notre solution étant sandboxed, cette DLL n’existe pas le GAC. Comment alors forcer SharePoint à chercher la DLL dans le contexte de notre collection? La réponse: il faut ajouter une seul ligne au XML précédent (entre la 10 et la 11)
1: <Solution SolutionId="e8860d27-0866-4b5b-a957-25a1de9e5f7c" xmlns="http://schemas.microsoft.com/sharepoint/" />
Le SolutionID (avec bien entendu le GUID correspondant) va permettre de retrouver la DLL sandboxed qui va bien, et ainsi faire fonctionner notre page!
- Julien!