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. –>
The SharePoint Swiss Army Knife 
Are you **sure**?? This seems like very bad practice to me. Put your code in the GAC and it is fully trusted, sure. But make the web application fully trusted and the change applies to *all* code hosted by that web application.
So now you don’t just need to check for security flaws in your code, but flaws in every piece of custom code deployed to that web application!
Then what if someone in a few months time decides its a good idea to put the web application on the Internet? Now your server is wide open for attack.
You’re right that CAS policies are difficult and often the only solution is to deploy to the GAC. But at least you are fully trusting code you know about, because you wrote it.
More info on Stack Overflow: http://stackoverflow.com/questions/461650/asp-net-trust-level-full
Hey Alex, thanks for the input.
For the reasons you stated, that’s why I’m starting to prefer deploying code to the bin fully trusted for some scenarios. Since I wouldn’t deploy any code that isn’t trusted in the first place, I wouldn’t really need to worry about needing to check for security flaws.
For internet facing web applications, if you don’t use CAS would you prefer for the code to be in the GAC and made available to all web apps or put into the bin and scoped to the web app? Also, chiming off that Stack Overflow link you posted, if you utilize SharePoint security best practices, the app pool account really wouldn’t have any worthwhile permission sets to do anything with the OS right?
Basically, if you trust the code enough to deploy to the GAC, why wouldn’t you want to deploy to the BIN with the same trust level? That way, we can at least prevent other web apps from running that code.
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.