SharePoint Journey: SharePoint Sandboxed Solutions Why are Use What are Benefits

Sandboxed solutions also offer a way to build SharePoint Web Parts and deploy them to a site without needing administrative intervention---that is, you can deploy a Web Part to a SharePoint site and have it run in the context of that site either in an on-premises instance of SharePoint or in the cloud using the hosted version of SharePoint.

Some of the key takeways from the session at #SPC09 were that Sandboxed Solutions are the preferred approach for all WSP deployment scenarios. The only reason NOT to use them is where it doesn't support what you are doing.

"Any solution that is created for Sandbox can be deployed into a special Solutions Gallery in the site-collection called SOLUTIONS GALLERY. And all these solutions that are deployed here can be activated from a menu (ECB menu) on that solutions gallery itself, hover around the item and you will get a ACTIVATE/DEACTIVATE menu. For all this to work properly we have to make sure that the "Microsoft SharePoint Foundation User Code Service" is starting on one or more of the servers in the Farm. You can confirm whether the service is running or not by checking the sandbox resource quota that is available on the top of the same page (Solutions Gallery Page). All of the resource assignment and monitoring for the Sandboxed solution can be controlled from Central Admin app.
Sandboxed Solutions to work need these 3 thing:

User Code Service (SPUCHostService.exe): this service will decide whether the box on which this service is running will participate in the Sandboxed solutions are not. This should run either on one box or more for sandbox solutions to take advantage of the server and run it on that server.

Sandbox Worker Process (SPUCWorkerProcess.exe): This is the actual process in which the Sandboxed Solutions run.

Sandbox Worker Process Proxy (SPUCWorkerProcessProxy.exe): If you have already studied and are aware of the new Service Application architecture then you get this one, this is the proxy which the web-app will use form the proxy group to use the sandbox."
INTRO: Sandboxed Solutions in SP2010

10 reasons to use Sandboxed Solutions

Sandboxed solutions are secure.

Sandboxed solutions can be monitored.

Sandboxed solutions do not affect other sandboxed solutions, well atleast not in other site collections is what I mean.

Sandboxed solutions do not touch the file system for the most part

Sandboxed solutions skip application pool recycles, so debugging is not such a pain.

Sandboxed solutions allow the site collection administrator to perform deployment and upgrades

Sandboxed solutions make CAS policies look like the out of style hairstyles of 1980s

The Solution validation framework for sandboxed solutions is exntensible, simply inherit from the SPSolutionValidator base class.

Sandboxed solutions remove the need for line by line code reviews

Sandboxed solutions allow you to offer different level of SLAs to different site collections using Resource Quotas.

Source: Sahil Malik

What is supported by sandboxed solutions?

Basically it is a narrowed down subset of the SharePoint OM. This is controlled with VS2010 by selecting your Visual Studio project as a sandboxed solution. It will hide any methods/classes that are not available automatically.

The following capabilities and elements are available in sandboxed solutions:

List definitions
List instances
Onet.xml
WebTemplate Feature element instead of Webtemp.xml
Content Types/Fields
Navigation
Module/files
Feature callouts
Web Parts derived from WebPart
Event receivers
- SPItemEventReceiver
- SPListEventReceiver
- SPWebEventReceiver
Custom Actions
Workflows

What is not supported by sandboxed solutions?

The following capabilities and elements are not available in sandboxed solutions (from MSDN):

Custom Action groups
HideCustomAction element
Content Type Binding
Web Application-scoped Features
Farm-scoped Features
CustomPropertyToolPart Class

(not on MSDN)

programmatic workflow
Event receivers
- SPLimitedWebPartManager
timer jobs
visual WebParts
SharePoint mapped folders (e.g. "_layouts", and "images")

The following .NET namespaces are not supported by sandboxed solutions:

ADO.NET
System.IO
System.Security.Cryptography
System.Web.UI.ClientScriptManager

Top 10 things to consider when writing SandBoxed Solutions

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.

SandBoxed solutions don’t 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).

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 can’t 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.

In #3, I lied about not being able to deploy stuff to GAC. WebParts that are sandboxed solutions do deploy the DLL to GAC.

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 it’ll 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??)

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.

Sandboxed solutions don’t 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.

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.

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 monitored-

AbnormalProcessTerminationCount

CPUExecutionTime

CriticalExceptionCount

InvocationCount

PercentProcessorTime

ProcessCPUCycles

ProcessHandleCount

ProcessIOBytes

ProcessThreadCount

ProcessVirtualBytes

SharePointDatabaseQueryCount

SharePointDatabaseQueryTime

UnhandledExceptionCount

UnresponsiveprocessCount

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.

Solution Monitoring

Administrators can monitor a solution and set a quota for how many "resource points" it can use in a day. There are various measures that build up points for a solution.

Add-PSSnapin Microsoft.SharePoint.Powershell
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
$s=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$s.ResourceMeasures \| Select-Object Name,ResourcePerPoint

Server Default

The default quota is 300 resource points a day, if you exceed that your solution is "cut off". The below table shows how many instances of a resource measure it takes to build a resource point e.g. 1 "AbnormalProcessTerminationCount" is one resource point, so 300 of these would "cut off" the solution.

Measure	Resource Per Point
AbnormalProcessTerminationCount	1
CPUExecutionTime	3600
CriticalExceptionCount	10
InvocationCount	100
PercentProcessorTime	85
ProcessCPUCycles	100000000000
ProcessHandleCount	10000
ProcessIOBytes	0
ProcessThreadCount	10000
ProcessVirtualBytes	0
SharePointDatabaseQueryCount	20
SharePointDatabaseQueryTime	120
UnhandledExceptionCount	50
UnresponsiveprocessCount	2

Solution Validators

Allow custom validation of a solution, installed at the farm scopeInstalled in a FeatureActivated eventOnce deployed, when you attempt to deploy a solution that breaks a validation rule, an error is displayed.