SharePoint 2010 Sandbox Web Part Properties

I had the pleasure recently of creating a custom web part which had to live inside a sandbox solution for SharePoint 2010.  SharePoint 2010 Sandbox solutions are great in enterprise environments when the resources are shared and the farm is locked down.  However it calls for a major change in the way we create web parts today and the limitations of the partially trusted calls in the SharePoint.dll can be a challenge.  One of the major drawbacks being that the new Visual Web Part cannot be used in the sandbox because of the need to deploy the ascx file that is a part of the visual web part to the file system (not allowed in the sandbox).  This leaves those of use used to creating web parts visually in MOSS 2007 with the need to revert back to the days before the notion of building a “SmartPart” or “Visual Web Part”  by leveraging control templates and Web User controls.  Now we take a step back to writing web parts strictly with code once more.

Another one of the hurdles with running in the sandbox is that all web parts must inherit from “System.Web.UI.WebControls.WebParts.WebPart” instead of “Microsoft.SharePoint.WebPartPages” (which is not allowed)  when running in the sandbox.  This means the traditional means of creating custom Web Part Properties using the ToolPart object in SharePoint is not available.  Thus one must now rely on how these custom properties are created when dealing with ASP.Net Web parts.  Which by the way (as is obvious in the sandbox restriction) is now the preferred way to create web parts.  ASP.Net Web Parts have an equivalent class to the “ToolPart” class called the “EditorPart”.  This class essentially works the same as before.  There are a couple of basic changes:

1. In your web part you need to override the following methods:

        public override object WebBrowsableObject






         return this;





        public override EditorPartCollection CreateEditorParts()




            ArrayList editorArray = new ArrayList();



            CustomToolPart edPart = new CustomToolPart();


            edPart.ID = this.ID + "_editorPart1";


            edPart.Title = "Custom Properties";            




            EditorPartCollection editorParts =


              new EditorPartCollection(editorArray);


            return editorParts;




2. You then need to create your custom properties section which inherits from the EditorPart class.  Here you will override the Create Custom controls, Apply changes, and SyncChanges methods to implement your class.  A sample can be found below using the EditorPart class link.


Bottom line if you have web parts today which you plan to more to SharePoint 2010 as a sandboxed solution you might need to update the web parts if they have custom property panes.  It is also a best practice to create all web parts as ASP.Net Web Parts instead of SharePoint Web Parts. 

Here is a list of the available SharePoint DLL APIs


Microsoft.SharePoint Except

SPSite constructor

SPSecurity object

SPWorkItem and SPWorkItemCollection objects

SPAlertCollection.Add method

SPAlertTemplateCollection.Add method

SPUserSolution and SPUserSolutionCollection objects



Microsoft.SharePoint.Utilities Except

SPUtility.SendEmail method

SPUtility.GetNTFullNameandEmailFromLogin method


Microsoft.SharePoint.WebPartPages Except

SPWebPartManager object

SPWebPartConnection object

WebPartZone object

WebPartPage object

ToolPane object

ToolPart object


ASP.Net Web Part Overview -

EditorPart -

Comments (2)
  1. schoie1981 says:

    no too bad

  2. weshackett says:

    The Community Kit for SharePoint: Developer Tools Edition will contain a Visual Sandbox web part. This will provide a visual ascx control design surface and still deploy to the sandbox.

Comments are closed.

Skip to main content