Best Practices for Developing Sandboxed Solutions in SharePoint 2010
Applies to: SharePoint Foundation 2010
Available in SharePoint Online
This topic describes some best practices in developing sandboxed solutions.
Warning
The Sandbox Solution framework provides a mechanism for executing user-provided code outside of the IIS worker process. The Sandbox Solution framework should not be used as a mechanism for enforcing security boundaries when executing user code. Sandbox Solutions are not supported as a security boundary with user code, especially code of unknown origin. We advise against executing Sandbox Solutions of unknown origins.
Avoid Creating Static Members in Sandboxed Code
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.
Avoid Throwing Unhandled Exceptions
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.
Use Both the AllowPartiallyTrustedCallers Attribute and the SharePointPermission Attribute
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.
See Also
Concepts
What Can Be Implemented in Sandboxed Solutions in SharePoint 2010