Execution models for SharePoint 2010: Part 3 – Sandboxed solutions

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.

Execution identity

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:




Execution models for SharePoint 2010: Part 2 – bin/CAS

In my previous post I covered deploying your SharePoint 2010 solutions to the GAC as farm wide full trust solutions. In this post I will cover another option to deploy your solutions, the bin/CAS model.

So what does bin/CAS mean?

The bin/CAS model basically means that your solution assemblies are deployed to the bin folder in the root of your web application folder structure. There are two main advantages to this approach, the first is that the assembly is isolated from any other web applications on your server by virtue of the fact that it resides in the bin folder.

The other is that the assembly is now subject to the Code Access Security policies defined in the web applications web.config file.

So overall this is a much secure option that the full trust model described in part 1.

So what’s the catch?

Well the main catch is that because your assembly resides in the bin folder it can only be loaded by the web applications IIS worker process which means that any SharePoint component that isn’t run within the IIS worker process like timer jobs for instance cannot be deployed in this way.

Another downfall is that because the assembly is restricted by the CAS policies of the web application if your assembly needs to do anything outside of the default wss_minimal and wss_medium trust policies you either need to elevate the whole web application to full trust by changing the trust level in web.config which is not recommended or define your own custom policy file which can be a pain to get right.

Example of default policy files defined in web.config:


      <trustLevel name=WSS_Medium policyFile=C:\Program Files\Common Files\Microsoft Shared\Web
Server Extensions\14\config\wss_mediumtrust.config />

      <trustLevel name=WSS_Minimal policyFile=C:\Program Files\Common Files\Microsoft Shared\Web
Server Extensions\14\config\wss_minimaltrust.config />


Example of default setting for which policy file to use. Remember that this setting only applies to assemblies deployed to the bin folder not to the GAC. All assemblies in the GAC will run in full trust.

<trust level=WSS_Minimal originUrl=“” />

Example of elevating whole application to full trust (not recommended).

<trust level=“Full” originUrl=“” />

Take a look at the wss_minimaltrust.config policy file located in the 14/CONFIG folder of your SharePoint implementation for an example of what a policy file looks like.

So how do we deploy to the bin?

In part 1 we create an event receiver project to deploy the assembly to the bin folder instead of the GAC we simply select the project file in Visual Studio and change its Assembly Deployment Target property to WebApplication as shown below:

Now when we package our solution and take a look at the manifest.xml file we see the following:

<?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=WebApplication />
<FeatureManifest Location=EventReceiverDeploymentExample_Feature1\Feature.xml />

When we deploy this solution the assembly will now be deployed to the bin folder and be subject to the CAS policies defined in the web.config file.

So what does this mean for our custom code?

The bin/CAS model is only suitable for code that will run within the IIS worker process meaning that timer jobs, service applications and workflows cannot be deployed using the bin/CAS model. It also means that you only have access to a subset of the SharePoint API that is defined in the CAS policy selected in the web.config.

The bin/CAS model is no longer a recommended approach in SharePoint 2010 as the Sandboxed and hybrid approaches offer a better tradeoff between security and ease of deployment.

If you want to extend the default policy files and deploy a custom CAS policy with your solution then you have to do a couple of things:

  1. Define your custom policy file and package it up for deployment in your custom solution. There is a good blog post on how to do this and a helpful template to use in this blog post here http://blog.mastykarz.nl/working-easier-custom-cas-policies/
  2. Reference your custom policy file in the web.config of your web application

    <trustLevel name=WSS_Minimal_Custom policyFile=C:\Program Files\Common Files\Microsoft Shared\Web
Server Extensions\14\config\wss_mediumtrust.config />

      <trustLevel name=WSS_Medium policyFile=C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\config\wss_mediumtrust.config />

      <trustLevel name=WSS_Minimal policyFile=C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\config\wss_minimaltrust.config />


<trust level=WSS_Minimal_Custom originUrl=“” />

In part 3 I will discuss the recommended approach for secure deployment of custom code using the Sandbox solution feature in SharePoint 2010.
kick it on DotNetKicks.com

Execution models for SharePoint 2010: Part 1 – Full Trust

What choices do we have?

In the days of MOSS 2007 and WSS 3.0 you had a couple of choices when deploying code to your server farm, Full Trust GAC deployment or bin/CAS deployment. With SharePoint 2010 you have another two options.

The two new options in SharePoint 2010 are Sandboxed solutions and a hybrid approach that gives you the ability to develop Sandboxed solutions that can call out to full trusted proxies.

For more reading to get an understanding of the execution models in SharePoint 2010 check out this MSDN article http://msdn.microsoft.com/en-us/library/ff798421.aspx

In part one I will discuss Full Trust deployment which is the easiest and most straightforward was of deploying solutions mainly because of the added complexity of getting the Code Access Security policies right in the bin/CAS model.

Most .Net developers will be familiar with deploying their assemblies to the GAC, we will all know that the assemblies have to be strongly named and we all know as SharePoint developers how to deploy our solution assemblies into the GAC but below I will outline exactly how to do this with SharePoint 2010.

We will create a basic event receiver and deploy this as a Full Trust solution to the farm then I will outline exactly how deploying our solution as Full Trust affects what the event receiver can do and what it can access.

  1. Create a new Event Receiver project in Visual Studio
  2. When you click ok you will be prompted to either deploy the solution as a Sandboxed solution or as a Farm Solution. We want to choose a farm solution which is basically saying we want to create a Full Trust solution that will be deployed to the server farms solution store. That also means that the assembly will be deployed to the GAC on every web server in the farm.
  3. VS will now ask you what type of event receiver you want to create, it doesn’t matter at this point because we are deploying a Full Trust solution which means that we can create any type of SharePoint component we like.
  4. VS will now create your project structure and give you some default code for your event receiver. We won’t create any functionality as our goal is just to show how to deploy the solution as full trust and what that actually means.
  5. Right click on the project file and select “Package” this will create our solution file (.wsp) in the bin folder of our project.
  6. When we open up the manifest.xml file within the solution file we can see that our assembly is being deployed to the global assembly cache (GAC)<?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 />

Great our assembly is in the GAC but what does this mean?

Well it means that any process can now load and use this assembly, only being restricted by the identity the process is running under. For example this means that it can be loaded by the, IIS worker process (w3wp.exe), the timer job process (owstimer.exe) and the workflow engine process. It also means that the code has no restrictions on what it can access outside of the assembly i.e. WCF web services and databases etc. Most importantly though it means it can access the full SharePoint object model and the full .Net framework class library.

Assemblies in the GAC will not be subject to the CAS policies defined in the web applications web.config file

That’s all good so why isn’t every solution a full trust solution?

Well in my experience nearly all MOSS 2007 solutions were deployed to the GAC as full trust solutions. This is mainly because the bin/CAS approach was hard to get right and most of the time offered little benefit over a GAC solution, bear in mind though that for security conscious applications like shared web applications and public facing internet sites that you may want to put in the effort to isolate your custom code at the web application level and deploy your solutions to the applications bin folder. I will cover this further in part 2.

In SharePoint 2010 however we get the option of a Sandbox solution and hybrid approaches which could offer you the best of both worlds.

In summary full trust solutions are often the easiest and straightforward solutions to deploy, however you must make sure that you fully trust the code being deployed as it can have farm wide performance and stability issues if the code crashes or causes memory leaks. The other issue is of course a potential security flaw in your code can compromised your whole server farm.

Another downside to full trust solutions is that I.T policies may be in place that mean full trust solutions are prohibited or may be subject to a full code review before being deployed.

For further reading on full trust solutions you can check out the MSDN article here which gives you some nice diagrams on exactly how SharePoint handles loading full trust assemblies. http://msdn.microsoft.com/en-us/library/ff798425.aspx

kick it on DotNetKicks.com

Some great SharePoint 2010 Training Material

Just came across this post on the SharePoint Team Blog which points to the SharePoint ignite site for Microsoft Partners.

The site contains some good material to get you started developing with SharePoint 2010 and also contains material for the IT Pro guys. The training comes in the form of videos, hands on labs and some assessments to help you learn along the way it’s definitely worth checking out the site if you’re interested in the upcoming release of SharePoint.