Understanding the SharePoint 2010 Sandbox limitations
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.
- The "real" Page object exists in the W3WP.exe process
- The Sandboxed Execution Manager serializes information from the fully-trusted objects (see below)
- 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
- The User Code Service reuses or spins up a Sandbox Worker process and sends request to the worker process
- The User Code Worker Process recreates a HttpContext and the Page object.
- It then creates a Form, Web Part Manager and a Zone before it processes the page.
- 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)
- Data is once serialized and sent back to the execution manager
- The information is put back into the "real" objects (Web Part properties, view state, controls state...)
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)
- Workarounds and alternatives by Waldek Mastykarz: http://blog.mastykarz.nl/dynamically-loading-javascript-sandbox/[Added after initial post]
- 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...
17 Comments
Brian Bedard said
What? The ClientScriptManager isn't accessible? How do we emit javascript to our controls? That seems safe enough to me. This seems very limiting...
Wictor said
You're correct. The ClientScriptManager is not available - you have to resort to other options
Trackback said
Top News Stories Benchmark Test Results Show SharePoint Ready For Enterprise Content Management Scale
Rick said
The System.Web.UI.Page class does not have a Files property. What are you referring to?
Rick said
What are the "other options" to useing the ClientScriptManager? I know you can put script in a LiteralControl and add it CreateChildControls. Are there other alternatives?
Rick said
What are the "other options" to useing the ClientScriptManager? I know you can put script in a LiteralControl and add it CreateChildControls. Are there other alternatives?
Steven said
Why are ribbon actions in the “Solutions” tab in the Solutions Gallery in a Records Center site collection? The same sandbox solution can be activated in another site collection in the same web-app but the buttons for activation in the records center solution gallery remain disabled.
Wictor said
Page.Files was a typo, corrected to HttpRequest.Files
Vincent Runge said
Thanks Wictor!
Intekhab said
I tried to write some string using this.Page.Response.Write("intekhab");, but not able to write using sandbox solution.
S said
Hi Wictor, would you have any advise on how to move web parts that include fairly basic tool parts into the sandbox? Have you done this yourself, maybe by storing the configuration in some other, sensible and accessible, place (e.g. lists)? Otherwise I guess the solution for us will be to deploy two sets of web parts, 1st set, without editor parts, will go as sandboxed solution, and 2nd, with editor parts, would go as farm solution. Any thoughts on this will be highly appreciated. Thanks and greets, /S
Stephan said
Hi Wictor, is it possible to close a dialog in which the sandboxed webpart is shown from code behind ? Thanx Stephan
Stephan said
Hi Wictor, is it possible to close a dialog in which the sandboxed webpart is shown from code behind ? Thanx Stephan
Stephan said
Hi Wictor, is it possible to close a dialog in which the sandboxed webpart is shown from code behind ? Thanx Stephan
Jason said
That really helps understanding few things. Redirection should have a simple solution other than the whole SOD javascript solution. I was browsing the whole day and found out a free download - http://shopsharepoint.com/products/95-sps.aspx It does what I want, redirection on configuring a passcode/Url on the toolpart
Irfan Bashir said
HttpContext.Current is null inside your "-ing" event receivers.
SharePoint Guru said
Found this great list of SharePoint Sandboxed solution Limitations:
http://www.sharepointdiary.com/2012/03/50-limitations-of-sharepoint-sandboxed-solutions.html