Lorsque l’on a installé la beta de SharePoint 2010 et que l’on veut jouer avec l’environnement de développement inclut dans Visual Studio 2010, on a le choix en terme de création entre 2 types de solutions SharePoint: une solution « bac à sable » (ou SandBoxed) ou une Farm Solution.

Les différences majeures entre ces deux solutions sont:

• Un environnement complètement séparé : les SandBox Solutions vont être exécutées par un service dédié nommé « Windows SharePoint Services User Code Host v4″; ce host va faire tourner le code de la solution avec le plus de restrictions possible (« WSS_Minimal »),
• Un déploiement possible par les Sites Collection Admins : du fait de son environnement très sécurisé en terme d’accès au APIs ou de process, l’impact du déploiment d’une telle solution est beaucoup plus simple pour les Farm Admins, qui laissent le soin aux Sites Collection Admins charger leurs solutions dans une Solution Gallery accessible sur chaque Site Collection.
• Pas d’accès aux designers: la possibilité si intéressante de pouvoir créer une webpart avec le designer de Visual Studio s’envole avec une solution Sandboxed : uniquement » l’ancienne façon » (comme en 2007, c’est à dire en ajoutant les contrôles au Runtime) est disponible. De plus, le dépoiement de fichiers dans le dossier _layouts, pour les Application Pages par exemple, est interdit dans une Sandboxed Solution.
• Contrôle fin possible pour chacune des Solution de type Sandbox: temps CPU utlisé, nombre d’errerus générées… si l’un de ces métriques est dépassé, la solution Sandbox est tout simplement désactivée.
• Déploiement par affinité : il est possible pour ces solutions Sandbox de gérer sur quel serveur faisant tourner le server « User Code » va être déployé la solution ; cela permet par exemple de mettre celles qui sont critiques sur des serveurs performants, et de parquer les autres sur un serveur moins… important ,
• APIs limitées : une solution Sandbox aura accès à bien moins d’APIs que celles présentes dans Microsoft.SharePoint.dll ; le mode User Code appliqué à un code tournant dans une Sandbox lui donne accès à un nombre limitée d’APIs: accès au site courant et sous sites autorisé, mais pas d’accès à l’élévation de privilèges,  ou le BCS. L’accès est donc limité au site courant (ce qui est cohérent avec le terme Sandbox ).

-> Une astuce pour pouvoir vérifier si le code que l’on a écrit dans sa solution va fonctionner une fois déployé consiste à changer la référence de  Microsoft.SharePoint.dll avec celle correspondant au set limité du User Code qui se trouve dans : …\14\UserCode\Assemblies.

• Plus de restrictions possible : par dessus ces limitations, il est possible d’ajouter une liste d’APIs bloquées supplémentaires (nommée Blocklist).
• Effet inverse avec un   »Full Trust Proxy »: Accès autorisé aux APIs  non disponibles dans une Sandboxed Solution en utilisant un « Full Trust Proxy » qu’il faudra coder soit-même; voici en gros les étapes àsuivre pour pouvoir réussir cela : 

1. Choisir quelle action l’on veut éffectuer dans le Full Trust Proxy, et l’implémenter dans une classe qui héritera de Microsoft.SharePoint.Usercode.SPProxyOperation,
2. Créer une liste d’arguments qui seront passés à votre méthode par une classe ( elle doit dériver de Microsoft.SharePoint.Usercode.SPProxyOperationArgs),
3. Compiler le tout dans le GAC en oubliant pas le Strong Naming,
4. Enregistrer le Proxy pour qu’il soit autorisé dans SharePoint (voir ici pour le script),
5. Utiliser dans son code Sandboxed le proxy créé avec la méthode SPUtility.ExecuteRegisteredProxyOperation.

Pour conclure les Sandbox solutions sont une bonne façon de simplifier et la tâche des administrateurs, mais aussi de mieux contrôler les packages développés en interne par un entreprise sur des packages tiers, qui pourraient mettre à genoux la ferme SharePoint si elles étaient mal développées, et déployées directement dans la ferme.