Les administrateurs de fermes SharePoint sont assez souvent réfractaires au déploiement de code personnalisé sur leurs environnements de production et il faut avouer que bien souvent, ils ont de bonnes raisons.

Voici quelques exemples de comportement que peuvent avoir les développeurs, qui font littéralement enrager les administrateurs :

• Passer le trustLevel à Full afin de faire fonctionner la WebPart qui s’exécute très bien sur la machine virtuelle de développement.
• Editer les web.config de tous les serveurs de production afin d’ajouter une chaine de connexion.
• Déployer des DLLs sur l’environnement de production qui sont compilées en mode debug, alors que le code est rempli de points d’arrêt.
• Oublier d’utiliser SPDisposeCheck pour vérifier que les DLLs qui vont être déployées n’ont pas de fuite mémoire.
• Déployer systématiquement toutes les DLLs dans le GAC.

Les solutions “Sandbox” ont été mises au point afin de réconcilier deux courants qui s’opposent en général au sein de l’entreprise, à savoir :

• Les équipes projet constamment à la recherche d’agilité afin de répondre rapidement aux besoins métiers
• Les exploitants du système d’information qui doivent assurer la stabilité et la sécurité des environnements qu’ils gèrent.

Voici comment les solutions “Sandbox” réconcilient ces deux courants :

Voici les différents éléments que peut contenir une solution “Sandbox” :

• Type de contenu
• Colonne de site
• Action personnalisée
• Composants WebPart
• Récepteurs d’événements
• Récepteurs de fonctionnalités
• Activités de flux de travail Microsoft SharePoint Designer personnalisées
• Logiques métier Microsoft InfoPath (qui n’ont pas besoin d’être approuvées par l’administrateur)
• Définition de liste
• Page de site

Attention : les WebParts intégrants des contrôles utilisateur (“Visual WebPart”) ne font pas partie de la liste des composants pouvant être ajoutés à une solution “Sandbox”.