Meilleures pratiques en matière de développement de solutions bac à sable (sandbox)
Dernière modification : mardi 12 avril 2011
S’applique à : SharePoint Foundation 2010
Dans cet article
Éviter de créer des membres statiques
Éviter de lever des exceptions non gérées
Utiliser les attributs AllowPartiallyTrustedCallers et SharePointPermission
Disponible dans SharePoint Online
Cette rubrique décrit quelques-unes des meilleures pratiques concernant le développement de solutions en bac à sable (sandbox).
Éviter de créer des membres statiques
Lorsqu’une solution en bac à sable (sandbox) spécifique est gérée pour la première fois sur un serveur donné qui exécute le Service de code en mode bac à sable SharePoint Foundation (parfois appelé Service d’exécution du code utilisateur), le service crée un domaine d’application pour la solution dans un processus de travail bac à sable (sandbox), et toutes les variables statiques figurant dans le code de solution sont chargées dans le domaine. Le domaine d’application reste actif une fois la solution en bac à sable (sandbox) terminée et est réutilisé si cette même solution en bac à sable (sandbox) fait l’objet d’une nouvelle demande, qui peut-être effectuée par un autre utilisateur sur une collection de sites différente. Un effet secondaire de ce système est le fait que les valeurs statiques ne sont pas rechargées, ce qui signifie qu’elles ne sont pas forcément appropriées lors de chaque exécution de la solution en bac à sable (sandbox) dans chaque contexte. Par exemple, supposons que le code de solution place SPContext.Current dans un champ statique nommé myContext. Si la même solution est demandée par une autre collection de sites, la valeur de myContext.Site est incorrecte.
Vous devez donc éviter de créer des champs et des propriétés statiques dans votre code bac à sable.
Éviter de lever des exceptions non gérées
Votre code ne doit pas lever d’exceptions qu’il ne gère pas. Cela est dû au fait qu’une exception non gérée dans une solution en bac à sable (sandbox) supprime toutes les solutions en bac à sable (sandbox) dans le processus de travail bac à sable, et pas simplement celle qui lève l’exception. Pour la même raison, il est recommandé d’intercepter toutes les exceptions et de signaler une erreur appropriée à l’interface utilisateur de la solution bac à sable, notamment à l’aide de la propriété Message de l’objet Exception.
Utiliser les attributs AllowPartiallyTrustedCallers et SharePointPermission
Le code dans le processus de travail bac à sable peut uniquement appeler des assemblys qui possèdent l’attribut AllowPartiallyTrustedCallersAttribute. Cela signifie que la plupart des assemblys personnalisés que vous déployez dans des solutions en bac à sable (sandbox) doivent posséder cet attribut. En outre, ASP.NET requiert la présence de cet attribut dans tout assembly comprenant une classe dérivée de WebPart. Pour ces raisons, Microsoft Visual Studio place cet attribut dans le fichier AssemblyInfo par défaut chaque fois qu’un projet solution en bac à sable (sandbox) est démarré. Toutefois, les assemblys qui possèdent cet attribut posent un problème de sécurité si le package de solution est installé en tant que solution de batterie de serveurs, car dans ce cas, tout appelant d’un niveau de confiance partiel pourrait appeler les classes de l’assembly dans un environnement de confiance totale. Si l’une des classes accède au modèle objet SharePoint, n’importe quel appelant d’un niveau de confiance partiel peut accéder au modèle objet SharePoint. Pour empêcher ceci, chaque classe dans un assembly identifié par l’attribut AllowPartiallyTrustedCallers qui appelle le modèle objet SharePoint doit être décorée avec l’attribut de demande d’autorisation suivant :
[Microsoft.SharePoint.Security.SharePointPermission(System.Security.Permissions.SecurityAction.LinkDemand, ObjectModel=true)]
De cette façon, seuls les appelants avec l’autorisation du modèle objet SharePoint peuvent appeler les membres de la classe.
La présence de l’attribut AllowPartiallyTrustedCallers n’est pas requise dans tous les assemblys des solutions en bac à sable (sandbox). Prenons par exemple un récepteur d’événement qui est appelé uniquement par l’EventCodeHost de confiance totale ; si l’assembly comprend uniquement un récepteur d’événement, l’attribut AllowPartiallyTrustedCallers peut être supprimé.
Voir aussi
Concepts
Qu'est-ce qui peut être implémenté dans une solution en bac à sable (sandbox) ?