To Sandbox or not to sandbox?

Microsoft SharePoint (Foundation) 2010 introduced the concept of running sandboxed code. This code can be deployed using WSP solutions, but the difference is it can be uploaded by authorized users at the Site Collection. Sandbox solutions run in a limited SharePoint Execution context and farm administrators can monitor and manage those solutions.

Because of the limited context, only a subset of the SharePoint Server Object Model is available. To quickly figure out, if a Sandboxed solution is possible (or even required), I created a small chart. The chart and information is not even close to complete and I will probably update these regularly.

For extensive information about the Sandbox in SharePoint 2010:

Oh, one more thing: Microsoft recommends Sandbox Solutions by default. So only use those Farm solutions if you really need to.

SharePoint 2010 design chart

The following Microsoft.SharePoint subset can be used with sandboxed solutions:

Namespace    Remark
Microsoft.SharePoint All, except SPSite constructor, SPSecurity, SPWorkItem and SPWorkItemCollection, SPAlertCollection.Add, SPAlertTemplateCollection.Add, SPUserSolution and SPUserSolutionCollection, SPTransformUtilities
Microsoft.SharePoint.Utilities SPUtility.SendEmail, SPUtility.GetNTFullNameandEmailFromLogin
Microsoft.SharePoint.Workflow SPWebPartManager, SPWebPartConnection, WebPartZone, WebPartPage, ToolPane, ToolPart

The following items can not be deployed using a sandboxed solution:

  • Site Definition
  • Application Pages
  • Farm and Web Application scoped features
  • Custom Actions Group
  • Custom Fields
  • Visual Studio Visual Web Part
  • Workflows with code
  • HideCustomAction
  • SharePoint Timer Jobs
  • Feature Receivers for Farm and Web scoped features