In this blog post, I will dissect every aspect of sandbox solutions as they apply to SharePoint 2010.
The below will turn into links as newer blog posts are published.
Some of the content below uses excerpts from my book on SharePoint 2010.
Table of Contents:
- The definitive guide (back to table of contents).
- The basics of a sandbox solution <-- you are here
- Sandbox solution architecture and restrictions
- Sandbox solution monitoring, management and deployment
- Sandbox solution validations
- Sandbox solutions full trust proxies
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. Custom code is that essential evil that is impossible to deliver real world projects without, but also cause the most headaches and effort.
A sandboxed solution is custom code that runs in a safe sandbox. It runs under some standard non-negotiable restrictions, so it can only do certain things and is prevented from doing certain other things. Mostly those certain other things that cause the most headache.
In addition to being restricted to doing only certain things a sandboxed solution can be monitored by two levels of administrators. The site collection administrator can monitor them through Site Actions -> Site Settings -> Solution Gallery, and the farm administrator can monitor them through central administration on a per site collection basis.
The farm administrator in addition to monitoring these sandboxed solutions, can also set limits on the resource allocation to sandboxed solutions on a per site collection basis using the standard quota mechanism. There are fourteen different metrics that contribute to such resource allocation, and it is done using a points based system. The farm administrator allocates a certain number of points to a site collection. If any sandboxed solution causes the number of points to jump over the total allocated points, all sandboxed solutions in that site collection are halted until a timer job that runs every 24 hours comes resets the site collection. Also, while you are under the allocated number of points, and you try doing something naughty like format my c: drive, the execution is blocked, a certain number of configurable points are charged, and the solution can attempt to do something naughty again (only to be blocked again, and charged more points!). On each of these metrics, you have the ability to set an absolute limit of resource points before the execution is halted, or an incremental number of points that are charged, without blocking resource allocation. This is useful since sometimes you want to halt execution and increment resource usage points! But sometimes you just want to count resource usage points, but not halt yet!
I like to think this level of monitoring very much like a family cellphone plan. Dad, Mom, Sister, and Son have a pool of 2000 minutes to share. Now if the Son somehow starts calling his russian girlfriend a little too much, everyone's cellphones quit working! Now dad has to call the phone company, and request the entire family plan to be allowed to run, and the offending solution (the son's cellphone), can now be blocked execution. Thus the farm administrator also has a concept called "Blocking sandboxed solutions". Certain sandboxed solutions that are known to be constantly troublesome, can be blocked by the farm administrator.
Finally, if you have code that is more restricted, and better monitored, and less damaging to your server environment in general, you can be more confident when you deploy it. Thus the biggest advantage of sandboxed solutions is that they can be deployed by the site collection administrator of a site collection, and they are deployed directly into the solution gallery in a site collection. Also, if a sandboxed solution does not deploy an assemblies, it can even be deployed by individuals with full control to a site collection. This greatly alleviates the headache of the farm administrator.
So, this was a brief overview of sandboxed solutions - they are restrictive and thus secure, better monitored, better administered, and easier to deploy. It is time to dive into this topic in much further detail.
Top 10 reasons to use Sandboxed Solutions
Top 10 things to consider when writing Sandboxed Solutions