Working with custom CAS policies is not trivial. Many developers find it challenging to figure out what permissions their code should have, so instead deploying safely to Web Application (BIN) they choose to deploy their assemblies to the Global Assembly Cache (GAC) granting their code full trust. There is however one trick that makes it very easy to find out what permissions you should grant to your code. Find out how to craft your custom CAS policies the easy way.
Recently I’ve been working on a SharePoint solution that was persisting some state information. Originally this solution was relying on Session State but because of some extra configuration complexity that using Session State with SharePoint requires we decided to replace the Session State with cookies. Although both approaches are not exactly the same they were both sufficient in the scope of the solution. And although you might expect no rocket science when working with ASP.NET cookies there are a few things that keeping in mind might save you some painful hours.
SharePoint 2010 ships with the SPSecurityTrimmedControl that allows you to conditionally display content to users based on their permissions. On top of that it gives you the ability to display content to anonymous/authenticated users only which unfortunately doesn’t work. And although you might want start off and develop something of your own, it turns out that for all this time there was a solution for this just around the corner.
Recently I was debugging a Web Part which had an issue with applying its changes. It required clicking the Apply/OK button twice in order to apply the changes. While this problem is quite commonly seen in different examples on the Internet, the solution is very simple.
For the last couple of weeks I spent some extra time on learning. I have decided to organize my knowledge and experience and fill in all the gaps.