SharePoint 2010 Sandbox Solutions are Bad

Guest Author: Doug Ware
Elumenotion, LLC

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.

Conclusion

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.

I think that they will be popular as a deployment model for applications that use the SharePoint.Client namespace with javascript and Silverlight. I can certainly hide the ribbon with javascript on the client � but I shouldn’t have to. I remain concerned that there is no good answer to #2 with regards to client side code. It would be nice if SharePoint allowed some sort of trusted caller infrastructure that allowed elevation to site owner. This should be possible at least with Silverlight.

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.

Guest Author: Doug Ware
Elumenotion, LLC

Doug Ware is a SharePoint expert, the creator of AppDev�s popular series of SharePoint 2007 courses, and the author of Elumenotion SharePoint Skinner – the ultimate SharePoint branding tool. Doug is the founder of Elumenotion, a SharePoint training and consulting firm located in Atlanta, Georgia and has completed numerous SharePoint implementations cover a wide variety of businesses. Doug is also the leader of the Atlanta .NET User Group and is a frequent speaker at SharePoint Saturday, code camps and other events.

[tweet]

7 thoughts on “SharePoint 2010 Sandbox Solutions are Bad”

  1. Sandboxed Solutions and SharePoint 2010…

    One of the most interesting new feature of SharePoint 2010 is something called Sandboxed Solutions. Think…

  2. Hi Doug,

    Very very useful R&D on sandbox. You have written this post at a very crucial time especially when pepole are just crazy about sanbox solutions. Development of business applications using sandbox way is really very dificult. I need to mentioned few more restrictions to your list
    1) You can’t acess the eventviewer for event logging [Where do I log the critical error messages then?]
    2) can’t access Dlls from BIN and resources files(.resx) and any other files from INETPUB.

    I am right now exploring more of such kind of restrictions which are the hurdles from the perspective of business application development.

    Please keep posted problem and their workarounds in Sandbox.

    Best Regards,
    Amol Gore

  3. I think you have to look at sandboxed solutions as part of a continuum from Client Side Object model > Sandbox > Managed code and see which offers the level of flexibility combined with control and risk for your requirements.
  4. Not sure SB Solutions are bad, but they definitely have much less promise than I initially thought they would. In addition to your points, you can not create a Visual Web part in Visual Studio 2010 as a SB Solution. To me that is the biggest issue because the people who are creating visual web parts are most likely the ones who would _need_ to deploy them as SB solutions.
  5. I totally agree with you. Sandbox solutions in the way they are don’t bring any advantages, because we have to develop specifically to it. a normal solution should run too as a sanbox solution.
  6. Well sahil if sandbox solution was too good then why sandboxed solutions are deprecated in sharepoint 2013? :)
  7. I can think about at least two very good cases when sandbox should be used:
     
    1. Custom actions to be added SharePoint Designer. It is extremely easy in sandbox: create xml manifest and a c# class code behind and you are done.
     
    Since workflows are very important for business automation this usage alone is golden.
     
    2. Custom web parts to enhance user experience.
     
    Often you want to improve user interface and your environment is the site collection itself. For example default Alerts subscription are not very user friendly. It is easy to create simple web part and upload it into sandbox. Or how about adding tabular view to your list? I have some examples of sanbox web parts at http://menu4web.codeplex.com.
     
    Now in 2013 considering the claim that sandbox is deprecated I am now even sure what is a good way to add custom actions to SharePoint Designer?
     
    Apps are cool but the framework is complicated. Try configuring Apps hosting on primus and you will see. Also it does not look like Apps will be able to do everything sandbox does.

Comments are closed.