Categories

Vanilla .NET
Non Techie
SharePoint
Bak2Basics
Books Authored
Books Reviewed
Community
Silverlight and WPF
WCF
Azure

Other material

Sandbox solutions are pretty damn good

Posted on 1/8/2010 @ 4:18 PM in #SharePoint by | Feedback | 11148 views

To say the least, my eyebrows were raised and my ears were perked when I read Doug Ware's article "SharePoint 2010 Sandbox Solutions are Bad". If you are unfamiliar with what a sandbox solution in SharePoint 2010 is, I would recommend reading this article here.

His basic complaint about sandbox solutions is around the restrictions they pose. For a moment let's consider what sandbox solutions give you. Sandbox solutions finally give you the ability to deploy at least some percentage of your code, with confidence that they wont kill your server. You as the architect can decide that percentage to be zero, or 100%, or some mixture of the both.

So if you think sandbox solutions suck, why not just go with 0%? So how can something extra be bad!??

Now let me talk about why I don't think I will ever see a project with sandbox solution being used at 0%. Or at least not a project that I will be a part of. Farm solutions and custom code is the number one necessary evil on SharePoint projects. It is also the number one issue that causes problems and updates. And it is also the number one issue that causes contention between IT Pros and developers. Sandbox solutions solve all of those problems.

In return you do give up some freedom! Freedom that Doug describes as his complaint around the height of those walls! My feeling is that there's been plenty of thought given to where and how those walls have been drawn. And where you do need to cross those walls, you do have the flexibility of writing of full trust proxy, or a custom WCF service. So again I don't see where the problem is!

Microsoft is giving you an arrow in your quiver to establish more control on your project, to guarantee better health of your server, to reduce contentions between IT pros and developers, to help ensure that your SharePoint server will upgrade easily in the future.

So here is how I see it! Complaining that sandbox solutions are bad, is a bit like complaining that the lock on your door causes a huge inconvenience when walking into your house. I mean what a pain it is to bring the keys out of your pocket, an unlock the door before you can get into your own house?

You know if you think that lock is such a pain in the donkey, don't use that lock! Write a solution validator to disable all sandbox solutions. I for one do intend to use that lock, and I intend to use it well.

I don't think Sandbox solutions are bad. In fact, they are a very welcome addition to SharePoint 2010. Not only do I intend to use it, I intend to grill anyone who insists on not using them. Consider yourself warned! :)

Update: Eugene and I are having a pretty good discussion on this on facebook too. Feel free to chime in.

Sound off but keep it civil:

Older comments..


On 1/8/2010 11:39:56 PM Jeremy Thake said ..
You forgot to mention our interview too ;-) For everyone reading, we did a podcast on this recently with @givencj:


http://www.sharepointdevwiki.com/display/SPPodCasts/2009/12/21/SPPodCast+003+-+Interview+with+Sahil+Malik+and+Chris+Givens


On 1/8/2010 11:42:34 PM Sahil Malik said ..
Yep - we made some good points there :)


On 1/9/2010 9:16:36 AM Michael Gannotti said ..
Great post and I agree with you. Sandbox solutions are not supposed to be the be all end all. They are another arrow in the developers quiver and because of their method of depolyment need safeguards around them.


On 1/9/2010 10:33:10 AM Sahil Malik said ..
Thanks Michael.


On 1/9/2010 11:42:41 AM Doug Ware said ..
My reply is here: http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=108

Let me say again that these posts are a direct reply to the "Sandbox should be your default choice" folks. With due respect to you and Michael, if you watch the PDC videos and read some of the blogs on this subject you'll see what I mean. For example, "What is a Sandboxed solution? A sandboxed solution is a new concept introduced in SharePoint 2010. A solution as I mentioned earlier is how you deploy new custom code to your SharePoint server." :)

I agree with that this is an 'arrow in the quiver.' But that is not how this thing is being evangelized. I don't want to see people make bad implementation decisions they will come to regret because they didn't realize what they were getting into!


On 1/9/2010 3:12:19 PM Sahil Malik said ..
Doug - more than an arrow in the quiver, I do think this should be your default arrow because of the advantages it brings. And yes it should be your default choice. To paraphrase Scot Hillier, "You should always write sandboxed solutions, until you can't!".

That makes total sense - try solve your problem using Sandboxed solutions .. but if you can't, use farm solutions.

Not sure why you say that is bad guidance?

S


On 1/9/2010 4:50:33 PM Doug Ware said ..
Near as I can tell, "Until you can't" seems to kick in as soon as you'd like to secure your data, use ASP.NET pages and controls, or interact with SharePoint. Like I said, I'm building a non-trivial sandbox application now. In the end it's going to be almost all javascript with a bit of Silverlight.

I'm going through the pain because I want it to run on SharePoint Online, but I think in the end it will probably have taken 3x as long to develop and will contain some serious compromises. As I get comfortable with the techniques I think the gap will narrow (but not close - no Intellisense and harder debugging for the js libraries is a major pain point), but the compromises will not go away.

This stuff doesn't exist in a vacuum. Compared to alternative approaches on the platform it is, in my opinion, extremely week and involves giving up a lot in return for very little. We'll have to see how it plays out, but I'll bet you a round of drinks in 2011 and another in 2012 that these bits will not be successful in corporate IT. If I am wrong I'll be happy to spring for the good stuff.


On 1/9/2010 6:42:13 PM Sahil Malik said ..
Doug, seriously these arguments are very weak! Lets see what you're saying here.

1. That you can do something now, i.e. deploy custom code for SharePoint online, while giving the hosting provider confidence that your code, no matter what won't break the server! Something you couldn't do in SP2007. .... That makes Sbox solutions bad??

2. You are saying that it took you 3x longer, and that as _you_ get better at javascript, this gap will narrow. So because debugging and writing in javascript is tougher, that makes sbox solutions bad? I guess that makes Ajax, and RIA apps bad too! Oh wait, that makes everything good on the internet bad!

3. Alternate approaches? Is there one? Don't tell me CAS was your plan on providing maintainable security on an SP site. We know, from experience, that wasn't a practical approach. Or atleast SBox sols are a much better approach.

S


On 6/1/2010 6:14:40 PM Shai Petel said ..
Sandbox solutions are bad and good, but not for any of the reasons brought in your or the original post.

They are great for evaluation periods, or for small deployments of customizations that will be used in just a few site collections.

The bad things are mainly maintanence (upgrading has to be done one by one), and performance. Having too many sandboxed solutions will kill your server, while having the same workload with same solutions on the same server but fully trusted will work great.

Restrictions? they must be there! after all, anyone (almost) can upload and deploy a sandbox solution... if there were no restrictions to what it can do that would be a major security breach and i don't know any IT person that will allow that (end users uploading custom code and running it off their server).


On 4/15/2011 5:34:09 AM Allan Agerholm Dahl said ..
Working with Sandboxed solutions I have experienced some issues with webparts running in the sandbox.

What I'm missing the most is that when running the webpart is my access to the regular Page object. See http://blog.a-dahl.dk/post/2011/04/11/Sharepointe28093Where-is-my-Page-object.aspx

Now I'm also missing the ability to see if a page is in edit mode most likely because the page object is gone... So any suggestions how to work around that?


On 6/10/2011 3:01:43 PM Darren Morgan said ..
Sandbox solutions are great when you want a feature to automate something that a Site Collection Administrator or Site Owner could do. Most creative activity in SharePoint sites is performed by site owners, but not all site owners are terribly well trained. So why not use a Sandbox feature or web part to help them out using a wizard? Need help setting permissions - activate a sandbox feature with a built in wizard. Want to cascade down branding for new sites without publishing - same. MSFT have basically given us a way to extend the core SharePoint UI so that using the site fits the business you are in - schools, banks, hospitals all need SharePoint but have different user stories.

I'm not too bothered that you can't elevate permissions, or access back end data. Most of the automation/UI extension described above runs just fine in the user context, especially for site owners. And yes you lose a few .NET controls, but you can always take the leap to WCF/Silverlight to fill any gaps - and XAML allows a much richer interface anyway. Ok, so you'll still have to deploy some farm-wide code for the WCF service but at least all the end user code will be managed locally. And all the hard work for database transactions is done by hand-crafted stored procs anyway, right? That way you can use your best developers to write an object orientated service framework (lots of juicy SQL/AD interaction) which your junior developers (or even Blend Designers!) can plug into safely to create lots of user-orientated sandbox solutions. It's a bit like the original separation between DBAs and Visual Studio coders when calling SQL - only it's highly trusted farm-level developers at the back end writing super-efficient super-robust code, while the customer-facing developer/designer focuses on enhancing the UI in a single site collection.

That doesn't mean develop on Production by the way. Even messing up a single page with some code is bad news for customers, so you still need at least one other environment to develop/stage in.

Sandbox solutions are also inextricably linked to custom web templates. You can tidy up and extend user-made web templates using VS2010 but you don't need to make them available across the farm like you do with site definitions.


On 12/12/2011 11:23:46 PM Anna Wojcik said ..
Sandbox solutions are great to deploy site branding (xsl, css, layouts, masterpages, images) We are running into many limitations when writing custom controls, I guess we rerely create silly "show list items" or "Display Hello world" webparts for our clients....


On 10/12/2012 3:10:00 AM Sharmila said ..
Hi,

I quiet like your articles:) its great! I am facing a problem while developing sandboxed solution. My requirement is to pass variables from javascript using AJAX POST call so that i can access it from code behind. Can you tell me how can I do it? I need to deploy an .aspx page and make ajax post call. Any help appriciated:)


On 12/9/2012 9:57:51 AM Zahid Zia said ..
Well sahil if sandbox solution was too good then why sandboxed solutions are deprecated in sharepoint 2013? :)


On 12/9/2012 1:49:11 PM Sahil Malik said ..
Zahid,

Well, it's not like their replacement "Apps" is without issues.


http://blah.winsmarts.com/2012-10-SharePoint_Apps_-and-ndash;_the_dark_side.aspx

And they are "deprecated" is bullshit. Yes I know MSDN says that, but as far as SharePoint is concerned, I've learnt not to believe MSDN too much. There is still plenty that sandbox and farm solutions are good for.

S