Recent discussions I’ve been involved with and blog posts have highlighted some of the SharePoint 2010 Sandbox limitations (either as bugs or as a feature). I have also talked about this during SEF 2010 and SPCSEA 2010. While writing my book SharePoint 2010 Web Parts in Action I had the opportunity to discover these limitations early on and  have learned to live with it. If you read my book you will find a lot of references to “this does not work in the Sandbox” (you’ve already ordered it huh? Otherwise it’s just one click away).

In this post I want to give you all a little head start on what really happens when executing SharePoint 2010 Sandboxed solutions. Focus is here on Web Parts.

SharePoint 2010 Sandbox Execution flow

Before building solutions for the Sandbox you have to know how it actually works, that will also make you understand in more details why some things work and some don’t.

  1. The “real” Page object exists in the W3WP.exe process
  2. The Sandboxed Execution Manager serializes information from the fully-trusted objects (see below)
  3. The serialized is sent to the User Code Service (in the OnPageLoadComplete event). It can be on the same or a specific Sandboxed App Server
  4. The User Code Service reuses or spins up a Sandbox Worker process and sends request to the worker process
  5. The User Code Worker Process recreates a HttpContext and the Page object.
  6. It then creates a Form, Web Part Manager and a Zone before it processes the page.
  7. After processing the Sandboxed Page object it retrieves the Response, View State, Control State (execution depends on for instance it is a post-back, export of web part, edit web part etc)
  8. Data is once serialized and sent back to the execution manager
  9. The information is put back into the “real” objects (Web Part properties, view state, controls state…)

Sandbox details

Serialized information

The information that is serialized includes but are not limited to:

  • ID’s of Form, Web Part Manager, Zone, Toolpane
  • Web Part properties
  • Options and properties of the Web Part and zone, such as chrome, zone customization, width, height…
  • View state
  • Control state
  • Server Variables (except APPL_PHYSICAL_PATH and PATH_TRANSLATED)
  • Request Headers
  • Input Stream
  • Current context (List Id, Item Id)
  • Query String

Non accessible or working stuff

You cannot access the following things from a Sandboxed Web Part, even though it compiles fine and executes without any errors:

  • The Cache object (works but is not serialized back)
  • The ScriptManager (works but is not serialized back)
  • The ClientScriptManager (works but is not serialized back)
  • The HttpRequest.Files collection (will never contain anything) [Corrected] 
  • The Master Page (works but is not serialized back)
  • Other Web Parts (since it creates a new Page and Form object and only adds your SB:d Web Part to the page)
  • Embedded resources (these are requested by the WebResource.axd and they cannot resolve the Sandboxed assemblies from the W3WP.exe process) [Added after initial post] 
  • You cannot use redirection (Response.Redirect, Server.Transfer or SPUtility.Redirect) [Added after initial post - Thanks Todd Bleeker] 
  • You cannot export a Sandboxed Web Part (it will just export the SPUserCodeWebPart) [Added after initial post] 

I hope this little post helps you out understanding why some of the stuff you expect to work doesn’t.

Feel free to comment on this and correct me if I wrote anything wrong…