Developing SharePoint Sandbox solutions – Tutorial

This is Tutorial post where you will learn what to do and what not to do while developing SharePoint Sandbox solutions.

Some of the key points you need to keep in mind from a Sandbox solution developers Perspective -

* You can create visual sandbox webparts using Visual Studio 2010 SharePoint Power Tools.

* Sandbox solutions are installed in Solutions gallery in site collection. This means it needs to be added to all the site collections where you want it to be deployed.

* You cannot implement Code access security in sandbox solutions.

* You can only access resources from within the site collection where you are installing the sandbox solution.
You are allowed to use :
SPSite.SPSite(Guid) – The GUID that is passed to this constructor must be the ID of the current site collection.
SPSite.SPSite(String) – The URL that is passed to this constructor must resolve to the current site collection.

* You cannot access database with sandbox solutions. By this I mean you cannot write code against values from SQL database.

* Only Features scoped to the site collection or the website are possible in sandboxed solutions. Farm and web application scope are not possible.

* Custom field types cannot be deployed in a sandboxed solution.

* Sandbox solutions cannot write to properties of the ASP.NET Page object (or its child objects) that hold objects of these unmergable types. The following table identifies some of these types.

•  ClientScriptManager – Sandboxed code should not write to the ClientScript property. However, client-side script can be registered with the page in other ways.
•  ScriptManager – Sandboxed code should not add a ScriptManager object to the controls collection of any object.
•  Cache – Sandboxed code should not write to the Cache property.
•  MasterPage – Sandboxed code should not write to the Master property. However, it can point the page to a different master page by writing to the MasterPageFile property.
• HttpSessionState – Sandboxed code should not write to the Session property.

* Defining a Custom Action Group and hiding a Custom Action are not allowed in sandboxed solutions.

* You cannot register a control candidate for a delegate control (Control element) in a sandboxed solution.

* You cannot Define a workflow Workflow element. This element is used only as part of coded workflows, which cannot be deployed in a sandboxed solution.

* Cannot use RunWithElevatedPrivileges in Sandbox solutions.

* Sandbox Code in the process cannot call to the network, write to the registry, cannot call any assembly that is not deployed to the global assembly cache. (An exception to this rule is assemblies that are deployed as part of the sandboxed solution) and cannot read or write to the file system (except that it can read and execute assemblies in the global assembly cache).

Other than these here are some of the blocked APIs that you cannot use in Sandbox solutions

*  Most of the Microsoft.SharePoint.Administration namespace, including the SPWebApplication and SPFarm classes.

* All of the control classes in the Microsoft.SharePoint.WebControls namespace. Code in sandboxed solutions is restricted to ASP.NET controls.

 * The WebPartMobileAdapter class.

 * The Microsoft.SharePoint.WebPartPages.WebPart class – Sandboxed solutions can include only Web Parts derived from the ASP.NET class System.Web.UI.WebControls.WebParts.WebPart.

* SPJobDefinition

* SPWebConfigModification

* RunWithElevatedPrivileges

Next we will look at how SharePoint restricts the access to all the functions available in Sandbox solutions >>