The other day I had to migrate a Microsoft Office SharePoint Server 2007 application to SharePoint 2010. This very simple database application uses a generated datalayer. This means, in this particular case, that the datalayer components of the application are in seperate DLL’s. I wanted to deploy these DLL’s to the BIN folder of the webapplication instead of to the Global Assembly Cache. This way I don’t need to put third party code in the GAC, and I have more control over what the code is allowed and not allowed to do.
Generating a custom CAS policy file vs manual creation of a custom CAS policy file
To give access to the code in the BIN folder of your web application you need to create a custom CAS policy file and then reference it in the web.config file of the web application. Further down in this post I will explain exactly how to do this.
Visual Studio 2010 has a built in mechanism to use custom CAS policies the easy way. Waldek Mastykarz has written a post on how to utilize this possibility:
http://blog.mastykarz.nl/code-access-security-policy-template-visual-studio-2010-sharepoint-developer-tools/
Using this method creates a custom CAS policy file for you and a reference to it in the web.config. The problem is that the name for the policy file is generated and has the form
wss_custom_wss_minimaltrust_GUID.config
Not very nice, is it? Imagine having multiple SharePoint solutions installed on your farm that each use a CAS policy file. There will be no easy way to tell which file belongs to which solution. Besides that I don’t like GUID’s in my file names. I like to have clear descriptive filenames where possible.
That is why I decided to “manually” create a CAS policy file and add it to my SharePoint 2010 Solution. It turns out that this is not so much work and gives you some more flexibility concerning naming. Also I think it is more clear for other developers that your solution contains custom CAS policies.
Adding custom CAS policies to a SharePoint 2010 Solution
To use a custom CAS policy file you have to do two things:
1) Create a custom CAS policy file and deploy it to the <SharePointRoot>/CONFIG folder.
2) Edit the web.config of your web application to use the custom CAS policy.
Creating and deploying a custom CAS policy file
The CAS policy file needs to be deployed to the <SharePointRoot>/CONFIG folder. To do this I’ve added a mapped folder to my SharePoint Visual Studio 2010 solution. This is where we are going to add the custom policy file.

Now I add a new textfile to the mapped folder and name it wss_custom_projectname.config
So in my case i call it wss_custom_caspolicytest.config. You can make up any name you want, but I recommend using the prefix wss_custom so your CAS policy files can be found easier and have consistant naming.
The contents of this file I copy from the <SharePointRoot>/CONFIG/wss_minimaltrust.config file. This makes sure I start out with minimal trust as a base and then add my own rules to it. Waldek Mastykarz has written an exellent article on how to find the policies that your code needs:
http://blog.mastykarz.nl/working-easier-custom-cas-policies/
You can use this trick to figure out what to add to the custom CAS policy file we’ve just added to the solution.
Editing the web.config file(s)
Now we should reference the new CAS policy file from the web.config file(s) of the web application. There are two entries in the web.config file that apply to CAS policies and are relevant for what we are trying to do here.
Tip: Add some code to your solution that uses the SPWebConfigModification class to edit your web.config files. Click here for a link to MSDN on how to do this. This makes sure that changes are propagated to all the web.config files in the farm. The details on how to do this for this specific situation is out of scope for this blog post.
There is a <trustlevel> entry in the system.web/securityPolicy node in the web.config. This defines the trustLevel name and file. In our case we need to add the following to the trustlevels in the web.config:
<trustLevel name="WSS_Custom_caspolicytest"
policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\config\wss_custom_caspolicytest.config" />
This defines a trust level with the name WSS_Custom_caspolicytest that is defined in the file we deploy using the mapped folder in the solution.
Next we need to get the web application to use the custom trustlevel we’ve just defined. To do this we must set the level attribute of the trust node in the web.config to our custom trust level. Default this attribute is set to WSS_Minimal.
<trust level="WSS_Custom_caspolicytest" originUrl="" />
that is it! Now you know how to get your code to use a custom CAS policy file.