Update: There is a way to load controls and insert code into the page rendering pipeline!
Update below: See #4. Basically, you can forget about using 99% of everything you know about ASP.NET if you want to sandbox.
I wish I could tell you that this was one of those posts where the title is a trick. It isn’t and there will be no ‘but in spite of all that it’s really great’ moral to this post. After spending a couple of weeks digging deeply into this architecture and its merits I am left profoundly disappointed by the reality of what is present in Beta 2. I hope that my position on this will change as we get closer to release and I also hope that if what follows is wrong the Internet will set me straight.
Most of my disappointment comes from the height of the walls around the sandbox and what I believe will be the result when this stuff hits the real world.
Issue #1 – No Access to SharePoint.WebControls Namespace
This one is really hard to understand – you can’t create a Web Part that uses any of the built in controls which you can use in SharePoint Designer! For example, I have a Web Part which I will talk about in a later post that hides the ribbon and the site actions menu if the user is not authenticated. The version I have won’t work as a sandbox solution because you can’t use the SPRibbon class in a sandboxed solution. So the sandbox solution has almost no control over the server side rendering of pages that contain sandboxed controls and much worse, prevent you from building pages that contain any of the built in SharePoint controls.
Issue #2 – No Elevation of Privileges = Less Security | More Complexity
In other words, sandboxed code can’t do anything that the current user can’t do. On the surface this seems reasonable. However, what if you want to collect data from a user and store the result somewhere that the user is unable to access? What if you want to display a subset of information to a user on a page but prevent access to the underlying data? Both are common requirements, but you can’t do it with a sandbox solution because your code is always under the user’s context. I predict that many people will take the easy way out and simply leave the lists that contain the data open to everyone. I also predict that many people will try to work around this restriction and create complex solutions that actually increase the attack surface.
Issue #3 – No Ability to Send Email
One of the methods that is explicitly blocked in the sandbox is SPUtility.SendEmail. As far as I know, there is no alternate method provided in SharePoint. However, you can use the ASP.NET email classes. The catch is that you can’t read information about the farm’s SMTP server so you have to create workarounds.
<Update> See this post: Participating in the Page Rendering Pipeline in SharePoint 2010 Sandbox Solutions – SPUserCodeWebPart for a way around this!
Issue #4 – Almost No Server Side Rendering – Forget About Using ASP.NET
I thought I would try to work around my ribbon issue with a simple custom WebControl. Turns out that, since the sandbox assembly is installed in ProgramDataMicrosoftSharePointUCCache, the regular worker process (w3wp.exe) that renders pages can’t load the custom UI assembly because it has no knowledge of the UCCache location. The same applies to code behind assemblies for ASPX.
You can create WebParts (sorta/kinda) but they are also extremely crippled. See http://blah.winsmarts.com/2009-12-You_can_deploy_WebParts_as_Sandboxed_solutions__but.aspx
There’s more, but those are my main issues. My belief is that sandbox solutions as they stand today are a dead on arrival technology – at least where the server side object model is concerned for controlling the UI.
However, you should not be fooled by the pronouncements that sandbox should be your default choice as was declared at PDC. If you are doing traditional development on a farm you own, the only thing you will get by going sandboxed is irritation from the sand.
Author: Doug Ware