Export (0) Print
Expand All

Best Practices for Developing Sandboxed Solutions in SharePoint 2010

SharePoint 2010

Last modified: April 12, 2011

Applies to: SharePoint Foundation 2010

In this article
Avoid Creating Static Members in Sandboxed Code
Avoid Throwing Unhandled Exceptions
Use Both the AllowPartiallyTrustedCallers Attribute and the SharePointPermission Attribute

Available in SharePoint Online

This topic describes some best practices in developing sandboxed solutions.

When a specific sandboxed solution is handled for the first time on a given server that is running the SharePoint Foundation Sandboxed Code Service (sometimes called the User Code Host Service), the service creates an application domain for it in a sandboxed worker process, and all static variables in the solution code are loaded into the domain. The application domain stays alive after the sandboxed solution finishes and is reused if that same sandboxed solution is requested again, perhaps by a different user on a different site collection. A side effect of this system is that the static values are not reloaded, and these values are not necessarily appropriate to every execution of the sandboxed solution in every context. For example, suppose the solution code puts SPContext.Current into a static field named myContext. If the same solution is requested from another site collection, the value of myContext.Site is incorrect.

For this reason, you should avoid creating static fields and properties in your sandboxed code.

Your code should not throw any exceptions that it does not handle. This is because an unhandled exception in a sandboxed solution kills all sandboxed solutions in the sandboxed worker process, not just the one that throws the exception. For the same reason, it is a good practice to catch all exceptions and report a suitable error to the user interface (UI) of the sandboxed solution, such as the Message property of the Exception object.

Code in the sandboxed worker process can call only assemblies that have the AllowPartiallyTrustedCallersAttribute. This means that most custom assemblies that you deploy in sandboxed solutions must have this attribute. Also, ASP.NET requires this attribute on any assembly that includes a class derived from WebPart. For these reasons, Microsoft Visual Studio puts this attribute in the AssemblyInfo file by default whenever a sandboxed solution project is started. However, assemblies that have this attribute create a security issue if the solution package is ever installed as a farm solution, because it would enable any partially trusted caller to call the classes of the assembly in a full trust environment. If any of the classes access the SharePoint object model, any partially trusted caller could access the SharePoint object model. To prevent this, every class in an assembly marked with the AllowPartiallyTrustedCallers attribute that calls the SharePoint object model must be decorated with the following permission demand attribute:

[Microsoft.SharePoint.Security.SharePointPermission(System.Security.Permissions.SecurityAction.LinkDemand, ObjectModel=true)]

This ensures that only callers with the SharePoint object model permission can call the members of the class.

The AllowPartiallyTrustedCallers attribute is not quite a requirement on all assemblies in sandboxed solutions. For example, an event receiver is called only by the fully trusted EventCodeHost, so if an event receiver is the only thing in the assembly, the AllowPartiallyTrustedCallers attribute can be removed.

Show:
© 2014 Microsoft