Top 10 reasons to use Sandboxed Solutions

Posted on 11/24/2009 @ 9:07 PM in #SharePoint by | Feedback | 2178 views

  1. Sandboxed solutions are secure.
  2. Sandboxed solutions can be monitored.
  3. Sandboxed solutions do not affect other sandboxed solutions, well atleast not in other site collections is what I mean.
  4. Sandboxed solutions do not touch the file system for the most part
  5. Sandboxed solutions skip application pool recycles, so debugging is not such a pain.
  6. Sandboxed solutions allow the site collection administrator to perform deployment and upgrades
  7. Sandboxed solutions make CAS policies look like the out of style hairstyles of 1980s
  8. The Solution validation framework for sandboxed solutions is exntensible, simply inherit from the SPSolutionValidator base class.
  9. Sandboxed solutions remove the need for line by line code reviews
  10. Sandboxed solutions allow you to offer different level of SLAs to different site collections using Resource Quotas.

Also read - Top 10 things to consider when writing sandboxed solutions

Sound off but keep it civil:

Older comments..

On 11/18/2009 6:15:32 AM Ricky Elias said ..
If workflows are deployed to a sandbox solution, will the workflow tasks still be run by the timer service - which is share between all apps on the farm?

If so, doesn't this create some need to be concerned about potential impacts the solution will have on all other solutions (sites collections) running on the Farm.

On 11/24/2009 9:46:29 PM Bil Simser said ..
@Sahil On a purely controlled intranet where the only developers are the SharePoint team, do you think Sandboxed solutions are a valid choice or would you just continue building things status quo?

On 11/24/2009 10:04:29 PM Sahil Malik said ..
Ricky - Excellent question! I don't know the answer, but I know how to get to the answer. Run a Sandboxed WF, and see what the process ID is. If it's the user code process - then you cannot go cross site collection. If it's timer service, then you can. I'll try it out in my spare time and let you know what I find, or if you get to it before me .. please illuminate us :)


On 11/24/2009 10:08:44 PM Sahil Malik said ..
Hey Bill -

Good to hear from you.

I would always always always always always try and solve a problem using Sandboxed solutions first! However, as any architectural solution goes, there are balancing acts.

Here is one example -

I am not too fond personally of the client object model, and the fact that it is rigidly tied to the sharepoint api. That goes against the whole tenets of SOA, where your objects and services are all about what you want to do, not what the API is shaped like. It's all about good architecture, and development practices. Your code should as closely align to your business needs, and as abstracted as possible to the underlying API. So, in that scenario, I would probably create a farm level solution with a proxy that exposes MY CUSTOM business objects.

Once I have done that, I would then use sandboxed solutions to use that proxy to my heart's content.

So yes, I would try and solve a need with sandboxed solutions first, but not avoid farm solutions as a hard & fast rule. But the bulk of your problem-solution in SP2010 should be sandboxed solutions.