0. Introduction▲
Par défaut, SharePoint autorise le déploiement des webparts dans 2 emplacements différents, le dossier bin, qui permet de rendre le composant disponible uniquement pour une application web particulière, ou alors le GAC, qui permet de rendre le composant disponible pour toutes les applications asp.net et SharePoint de votre machine.
I. Déploiement dans le GAC avec Visual Studio▲
Pour déployer une webpart dans le GAC, nous allons devoir signer notre assembly avec un nom fort, et ensuite utiliser la commande gacutil /i pour installer notre assembly dans le GAC.
Pour cela, on va passer par le solution explorer pour atteindre les propriétés de notre projet.
Pour signer notre assembly, dans les propriétés du projet, nous allons aller sur l'onglet « Signing », choisir de signer notre assembly, et donner un nom à la clé qui sera générée pour signer notre assembly.
Une fois ceci effectué, nous avons un nouvel élément qui fait son apparition du côté des éléments de notre projet.
De même, à chaque compilation, nous allons demander à visual studio de déployer automatiquement notre assembly dans le GAC.
Ici, dans l'onglet « build events » puis « post-build events command line », nous allons tout d'abord tenter de désinstaller l'assembly du GAC, ensuite, nous procédons à son installation, et pour terminer, nous redémarrons les services iis.
II. Déploiement dans le dossier bin avec Visual Studio▲
Pour déployer une webpart dans le dossier bin d'une application, on peut utiliser Visual Studio.
Dans le paramètre « Output », nous allons ensuite spécifier le dossier « bin » de notre application web.
Que nous choisissions de déployer notre assembly dans le dossier bin ou dans le GAC, la seule chose que nous ayons à faire une fois toutes ces étapes réalisées, est de compiler notre application ; Visual Studio se charge du reste !
Une fois le déploiement dans le GAC effectué, les assembly déployés fonctionnent par défaut en mode Full Trust, et aucune tache de configuration n'est nécessaire.
Cependant, lorsqu'elles sont déployées dans le GAC, les assembly fonctionnent en mode restreint, et il faut donc réaliser des taches supplémentaires, comme par exemple les autoriser depuis le web.config de l'application, pour autoriser leur exécution.
Remarque : A la place de redémarrer les services IIS, nous aurions pu tout simplement recycler le pool d'application, par exemple SharePointDefaultAppPool, concerné via la commande «cscript c:\windows\system32\iisapp.vbs /a "SharePointDefaultAppPool" /r » ce qui est beaucoup plus rapide et permet de gagner énormément de temps lors des phases de debug.
II-A. Déclarer l'assembly comme « sûre »▲
Une fois notre composant déployé, il va falloir autoriser son exécution.
Pour cela, nous allons devoir modifier le « web.config » de notre application et marquer notre dll comme sure.
Le web.config de l'application se trouve à l'emplacement « C:\Inetpub\wwwroot\wss\VirtualDirectories\ no_de_port_de_l_application\ », nous allons l'éditer.
Ouvrons le fichier avec n'importe quel éditeur de texte, puis localisons le noud « SafeControls ».
Nous allons ensuite rajouter un nouvel élément SafeControl, comme suit :
<SafeControl Assembly="Asp.netHelloWebPart" Namespace="Asp.netHelloWebPart" TypeName="*" Safe="True"/>
C'est terminé, notre contrôle webpart est déployé.
III. Elévation du niveau de confiance▲
Lorsque l'on déploie une webpart dans le GAC, notre assembly doit être signée.
Une fois cette opération effectuée, le code de notre assembly s'exécute en « full trust », et de manière globale, ce qui signifie que notre assembly peut être appelée de n' importe où et exécuter n'importe quelle instruction.
Ceci peut être un avantage certain, lorsqu'on a besoin d'utiliser une assembly sur plusieurs applications web par exemple, tout comme un réel inconvénient, quand l'assembly peut représenter un danger potentiel.
Ceci nous amène souvent donc à déployer nos assembly dans le dossier bin de l'application concernée.
Dans ce cas, lorsque nous aurons besoin d'utiliser notre assembly dans plusieurs applications web, il nous faudra à chaque fois déployer notre assembly dans chacun de leur dossier bin.
Cependant, les autorisations avec lesquelles vont s'exécuter notre assembly seront minimes, et il sera de notre charge d'élever explicitement leur niveau de permission.
Pour cela, nous avons 2 solutions :
- Modifier directement le « trust level » de notre application web dans son fichier web.config, en spécifiant un des fichiers « trust policy» préexistant, ou alors,
- Créer un nouveau fichier « trust policy » et le référencer dans le web.config.
III-A. Tour d'horizon des fichiers « Trust Policy »▲
Un fichier « Trust Policy » correspond à un ensemble de permissions prédéfinies.
Par défaut, Asp.net implémente 5 niveaux de permissions, qui sont Full, High, Medium, Low, et Minimal, qui sont définis dans les fichiers web_fulltrust.config, web_hightrust.config, web_mediumtrust.config, web_lowtrust.config, web_minimaltrust.config, stockés à l'emplacement « C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG » pour la version 2.0.50727 du framework .net .
Le niveau Full autorise tous les accès aux applications Asp.net.
En plus de ces niveaux de permissions asp.net qui peuvent s'appliquer également à wss 3.0 / moss 2007, de nouveaux niveaux viennent s'ajouter avec l'installation des produits SharePoint.
Ces niveaux sont Wss_Minimal, qui est le niveau par défaut, et Wss_Medium, qui sont définis dans les fichiers wss_minimaltrust.config et wss_mediumtrust.config et sont stockés à l'emplacement « C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\CONFIG ».
Par défaut, avec le niveau de permission wss_minimal, les seules permissions autorisées sont celles autorisées par le niveau web_minimal définit par asp.net + l'autorisation d'exécution de l'assembly + l'autorisation de connexion au niveau de la sécurité des webpart (mais pas le droit d'utiliser le modèle objet de SharePoint !).
Ci-dessous, un extrait du fichier « wss_minimaltrust.config »
<PermissionSet class="NamedPermissionSet" version="1" Name="SPRestricted">
<IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
<IPermission class="SecurityPermission" version="1" Flags="Execution" />
<IPermission class="WebPartPermission" version="1" Connections="True" />
</PermissionSet>III-B. Création d'un fichier « Trust Policy »▲
Nous allons à présent voir comment créer nos propres fichiers « trust policy ».
Le plus simple pour cela est de partir d'un fichier existant.
Dans notre exemple, nous allons créer un fichier « trust policy » qui, en plus d'autoriser la connexion de nos webparts, va également nous autoriser à utiliser le modèle objet de SharePoint.
Pour cela, nous allons commencer par copier le fichier « wss_minimaltrust.config » et le renommer en « wss_minimalwithobjectmodeltrust.config ».
Ensuite, au niveau du noud <SecurityClasses>, nous allons déclarer la classe de sécurité SharePointSecurity, car c'est elle qui contient la permission « ObjectModel ».
<SecurityClass Name="SharePointPermission" Description="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security,
Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"/>
Puis, au niveau du noud <PermissionSet Name= « SPRestricted »>, nous allons rajouter un noud enfant <IPermission> comme suit :
<IPermission class="SharePointPermission" version="1" ObjectModel="True" />
Les code groups permettent de définir à quel moment les conditions vont être exécutées en fonction de conditions définies au niveau du <IMemberShipCondition>.
Une fois ce fichier enregistré, il va falloir le référencer au niveau de notre wss_minimaltrust.config.
Pour cela, on va localiser le noud <trustlevel> dans le web.config de notre application, et rajouter un élément correspondant à notre fichier trust policy custom
<securityPolicy>
<trustLevel name="WSS_Medium"
policyFile="C:\Program Files\Fichiers communs\Microsoft Shared\Web Server Extensions\12\config\wss_mediumtrust.config" />
<trustLevel name="WSS_Minimal"
policyFile="C:\Program Files\Fichiers communs\Microsoft Shared\Web Server Extensions\12\config\wss_minimaltrust.config" />
<trustLevel name="WSS_MinimalWithObjectModel"
policyFile="C:\Program Files\Fichiers communs\Microsoft Shared\Web Server Extensions\12\config\wss_minimalwithobjectmodeltrust.config" />
</securityPolicy>III-C. Modification du « Trust Level »▲
Pour modifer le « Trust Level » d'une application web, rien de plus simple !
Il nous suffit pour cela de localiser la balise trust dans notre web.config, et ensuite de modifier l'attribut level, en fonction de notre besoin.
Par exemple, nous allons localiser
<trust level="WSS_Minimal" originUrl="" />
et le remplacer par
<trust level="WSS_MinimalWithObjectModel" originUrl="" />
Nous aurions également pu utiliser pour cette valeur l'un des 5 niveaux définis par asp.net (Full, High, Medium, Low, et Minimal)
Une fois cette modification effectuée, il nous faudra redémarrer nos services IIS, en utilisant la commande « IISReset », pour qu'ensuite les permissions définies dans notre policy file puissent être appliqués à toutes les assembly de notre application web.
IV. Ajout de notre webpart à la galerie de composants de webparts▲
Une fois que notre composant à été développé et déployé, il ne nous reste plus qu'à l'ajouter à la galerie de composant webpart de notre site pour pouvoir le rendre disponible.
Pour cela, rendons nous à la page suivante : http://url_du_site/_layouts/newdwp.aspx.
Il ne nous reste plus qu'à localiser notre composant webpart et l'intégrer à notre galerie.
Une fois intégré, notre webpart est disponible pour tous les sites de notre collection de sites, lorsque nous choisissons d'ajouter une webpart.
V. Conclusion▲
Dans cet article, nous avons vu comment nous pouvons utiliser visual studio pour déployer automatiquement nos webparts.
Cette solution est un réel avantage lors de phases de debug, cependant, elle ne convient absolument pas pour une mise en production ou une livraison.
Pour cela, nous verrons dans un prochain article comment déployer des webparts au travers de Features et de Solutions.