Here’s some food for thought if you’re developing custom SharePoint solutions that involve Visual Studio. These are just some things I’ve picked up along the way so feel free to comment if you’d like.
This is a much debated topic and further research should definitely be done on the merits of each approach when determining which method of code deployment should be used in deploying custom SharePoint DLL’s.
Using Code Access Security will introduce more elements of complexity to your custom SharePoint solution but may also be required in some environments. With that said, some custom SharePoint solutions will require that the code or DLL’s are deployed to the Global Assembly Cache (GAC) in order for it to even work in a SharePoint environment. This essentially renders the need for CAS irrelevant in some cases (I think?). Some examples of these special cases are workflows and event receivers. There are some other cases but I can’t remember them off the top of my head at the moment…
Deploying your code to the Global Assembly Cache is the easiest and most rudimentary way to deploy your code. For solutions such as custom web parts, this may be ok but in others this may not be acceptable. An example where this might not be acceptable are environments where the server is a shared resource amongst disparate organizations and code sharing should be prevented. To expand on that, consider if you had a custom web part that is configured to tap into some secret data sources that one organization can see but other organizations on other web apps on the server should definitely not be able to use it. Unfortunately, when code is deployed to the GAC, any web app will be able to activate the feature and execute the code.
A hybrid approach is to deploy the DLL to the web application’s BIN directory, much like you would when using Code Access Security, but you would also set the trust level of that web application to “Full” from the standard “WSS_Minimal.” Changing this trust level is analogous to deploying the code to the GAC whereas the code is fully trusted by the server, but having the DLL in the BIN adds a level of inaccesibility by other web applications. This is my current preferred method for deploying customizations since it gives me more flexibility in properly scoping my solutions and at the same time not as complex as having to implement CAS for everything.
<!– 11/04/09 Edit: I have since figured out how to effectively use Code Access Security with help from http://blog.tylerholmes.com/2008/11/creating-custom-cas-policy-file-for.html so I’ll be looking forward to using CAS more often now. –>