In part 1 and part 2 of this series of blogs posts I covered two execution models for SharePoint 2010 that we also had in SharePoint 2007. The Full Trust and bin/CAS models are still applicable in SharePoint 2010 but we have another candidate that makes deploying secure, isolated solution to your server farm a lot easier.
So what is a Sandboxed solution?
The Sandboxed solution feature in SharePoint 2010 gives another execution model that isolates the solution at site collection level and allows deployment of the solution to be handled by the site collection administrator. This takes the burden of managing these solutions off the IT team and can be managed through the site collection UI instead of central admin.
Most IT teams wouldn’t be happy with allowing end users to deploy custom code to their nice shiny server farm so sandbox solutions have a few restrictions that give the IT team some comfort. Firstly the sandboxed code is run in an isolated process that is run under the identity of a low privilege account. Secondly the code is subject to a special default user code CAS policy that can be located in the 14/CONFIG folder. This CAS policy defines exactly what code the sandboxed code can all out to.
When a request comes into IIS a component called the Execution Manager handles the request. The execution manager runs in the same application pool as the web application that received the request. The execution manager then routes the call to the SharePoint User Code Service (SPUCHostService.exe). The user code service can be running on the same server or can be load balanced across multiple servers for increased scalability.
The user code service will then create a new sandbox worker process (SPUCWorkerProcess.exe) or route the request to an existing worker process, this is where your custom code will actually run.
As you can see your code is isolated into the user code service so it can’t bring the web application down if something manages to crash the user code service.
Calling the SharePoint object model.
The CAS policy associated with the sandbox worker process defines which part of the SharePoint API the user code can access (specifically a subset of the Microsoft.SharePoint namespace), when you call into this subset of the SharePoint API, the sandbox worker process calls into a proxy process (SPUCWorkerProcessProxy.exe) which is a full trust environment that actually executes the SharePoint API code.
This worker process is governed by the web.config file located in the 14/UserCode folder, this sets the CAS policies and the trust level of the execution environment for all sandbox solutions.
If you attempt to use a method that is not available to sandbox solutions you will receive a MissingMethod exeption at runtime.
The sandbox worker process executes under a configured low level account and this cannot be changed at runtime within your sandbox code, this mean no SPSecurity.RunWithElevatedPrivileges.
In fact you cannot access the security token of the user executing the code at all but you can get an instance of the SPUser object that represents the user executing the code within the SharePoint context.
Site collection boundaries
Sandbox solutions are deployed to a site collection and are stored in the site collection solution gallery (_catalog/solutions). As a result sandbox solutions cannot access anything outside the hosting site collection.
File system restrictions.
Sandbox solutions do not have access to the file system so you cannot deploy any code into the SharePoint root such as User Controls or application pages. Also bear in mind when a file is deployed using a sandboxed solution and the type attribute is set to Ghostable or GhostableInLibrary then the file is still deployed but it is never deployed to the file system. Instead SharePoint will put the file straight into the content database and the file will always be served from the database.
Sandbox solutions are monitored by SharePoint itself and IT teams can configure through Central Administration the boundaries in which sandbox solutions can execute. If a sandbox solution hits any of the limits imposed then SharePoint will automatically terminate the sandbox process. There is a lot more to sandbox solution monitoring but I’ll try to cover this in another blog post.
So how do I deploy my solution as a sandboxed solution?
So if we take the solution we had from parts 1 and 2 all we need to do is select the project file in VS and change its Sandboxed Solution property to true.
One thing to notice is that the deployment target is set to GlobalAssemblyCache meaning the sandboxed assembly is stored in the GAC. We can see this in the manifest below.
<?xml version=“1.0“ encoding=“utf-8“?>
<Solution xmlns=“http://schemas.microsoft.com/sharepoint/“ SolutionId=“a12ef36a-3f79-4d8f-801f-b9ef56e6247f“ SharePointProductVersion=“14.0“>
<Assembly Location=“EventReceiverDeploymentExample.dll“ DeploymentTarget=“GlobalAssemblyCache“ />
<FeatureManifest Location=“EventReceiverDeploymentExample_Feature1\Feature.xml“ />
Sandbox solutions are now the recommended way of deploying secure custom code but they do have their restrictions so there is a trade-off. You may want to look at a hybrid approach which uses a full trust proxy to execute code outside the sandboxed environment, this allows you to still deploy code in a sandboxed solution but also call out to other resources using a proxy. I will cover hybrid solutions in part 4.
For more information see these links below: