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

4 thoughts on “Execution models for SharePoint 2010: Part 2 – bin/CAS

  1. Pingback: Execution models for SharePoint 2010: Part 3 – Sandboxed solutions « Lee Dale

  2. Pingback: SharePoint 2010 & CAS : le GAC n’est pas l’unique solution de déploiement de vos composants , The Mit's Blog

  3. Pingback: Hur gör man deploy på bästa sätt? | Sharepointkaos

  4. Pingback: How do you deploy the best way? | Sharepointkaos

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s