SharePoint 2010 Sandboxed Solutions: The basics

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

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 extensible; 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.

Top 10 things to consider when writing SandBoxed Solutions

In sequence to my previous blogpost about Top 10 reasons to use Sandboxed solutions, here are my top 10 things to consider when writing Sandboxed solutions. 1. Memorize this list - ContentType, Field, CustomAction, Module, ListInstance, ListTemplate, Receivers, WebTemplate, WorkflowAssociation, PropertyBag, WorkflowActions. This is what the elements.xml of a sandboxed solution can do. If you try and architect your solution that fits within the above, your SharePoint farm will treat you well. 2. SandBoxed solutions dont run in W3Wp.exe. They run in SPUCWorkerProcess.exe (UC = User Code, SandBoxed solutions were at one point called user solutions). Thus while Sandboxed Solutions are isolated by default, you can and should get further level isolation by running your sandboxed solutions on a dedicated server(s). 3. SPUCWorkerProcess.exe will prevent you from accessing anything outside the site collection where the solution has been deployed. Bye bye making web service calls over the internet, or accessing code that is not marked to allow partially trusted callers. You also cant deploy files to disk or add assemblies to the GAC in a sandboxed solution, and security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed. 4. In #3, I lied about not being able to deploy stuff to GAC. WebParts that are sandboxed solutions do deploy the DLL to GAC. 5. There is nothing fundamentally different between a sandboxed solution and a farm solution except how it is deployed, and what they may contain and do. Thus, you could deploy a Farm solution as a sandboxed solution, but itll just blow when it tries to do anything funky. You can and should prevent the uploading of sandboxed solution, that is not really a sandboxed solution using a custom SPSolutionValidator (codeplex project anyone??) 6. Regarding #3 and #4, if a sandboxed solution contains an assembly, only the site collection administrator can deploy it. However, if a sandboxed solution does not contain an assembly, anyone with full control on your site can deploy it. 7. Sandboxed solutions dont write anything to the SharePointRoot (Previously known as the HIVE). But if you deploy a sandboxed solution as a farm solution, it will create a directory in template/features/<yourfeaturename>.xml for instance. Remember #5 there is nothing fundamentally different between a sandboxed solution and a farm level solution .. just what they contain, what they can do, and how they are deployed. 8. Regarding #3 things that Sandboxed solutions cannot do if they NEED TO do those things, you should write a proxy class that runs in full trust outside the sandboxed worker process. This proxy has to be deployed as a farm level solution, but can be called by other sandboxed solutions.

9. Sandboxed solutions can be monitored using the Site Quota page at /_admin/siteQuota.aspx in your central admin. Monitoring is done on a point level system if your solution exceeds a certain # of configurable points (by default 300), all sandboxed solutions within the site collection stop working for 24 hrs, or until the timer job resets. The following metrics can contribute to this point -calculation, and thus the following things on a sandboxed solution can be monitoredo AbnormalProcessTerminationCount o CPUExecutionTime o CriticalExceptionCount o InvocationCount o PercentProcessorTime o ProcessCPUCycles o ProcessHandleCount o ProcessIOBytes o ProcessThreadCount o ProcessVirtualBytes o SharePointDatabaseQueryCount o SharePointDatabaseQueryTime o UnhandledExceptionCount o UnresponsiveprocessCount 10. If you can achieve a functionality using SandBoxed solution, but you insist on delivering that functionality as a Farm Solution, and you have no needs to backport to SP2007, I will personally come and interrogate you on your reasons for doing so.