Behind the Scences: CAS in Solution Packages
As I always mention in my presentations and articles (such as this one), I’m not too crazy about deploying everything to Bin folder (OverCASing). I believe There is a place for everything! Honestly , many stuff in SharePoint don’t work when executed from bin folder and more importantly, there are customers out there that don’t care (read it , they don’t want to pay for it !). I am not going to walk you through this discussion at all.
On the other hand, I know that there are many resources out there that talk about pros and cons of utilizing code access security in your solution packages and run your Web part assemblies (or your code in general) in a super sandbox mode, a.k.a Partially trusted environment. What I haven’t seen though is a complete explanation of what happens behind the scenes when you include code access security in your solution manifest file and what gets changes , where and when, a solution containing CAS settings gets deployed or retracted. I was mostly interested to see what happens when the solution package gets retracted.
Any Code that runs from the bin directory of an IIS Web application (SharePoint Web application is an IIS Web site all together) runs in a secure mode; therefore you have to explicitly give it the permissions it requires to function. Easiest solution (FWIW, the most stupid one ) is to raise the trust level of your Web application to full (in the Web.config file).The recommended approach is to elevate the permissions of the assembly by creating a new security policy file and point your web.config file to it. Thankfully, by using solution package concept, SharePoint provide a way for automating this process for ya.After you create a SharePoint Web application its Web.config looks like this:
Note: Only the sections of the web.config file that are related to this topic were included below.
[Xml]
[/Xml]
