Sharepoint permission exception when adding in your assembly

To me, Sharepoint technology as a derivative from ASP.net 1.1 or 2, the only difference is couple of new libraries and mostly pain will be from deployment of your webparts and features, etc. The coding itself sees no difference with normal C#/VB + ASP.net process when customizing your own ASP.net app. The worst nightmare might be the tackling with CAS(Code Access Security). Yes, that's right, the one who gives you rubbish like "request for SPPermission ... blah blah failed" etc.



You might enjoy a lot in coding sharepoint webparts and features. It won't bother you that much if you just play around with simple label controls on your webparts and not accessing other system resources. Once you want to do more with your controls on webparts and even , say do a databind to your datagrid which calls another object in your assembly which might retrieve data from sharepoint list or local system resource, the error message could be saying SPPermission request failed(roughly speaking). Obviously, sharepoint is restricting your code from executing to protect the system integrity or w/e the reason you might hate to guts... but anyway, There's a couple of things you might want to try from the level of least radical to the other end.

1. If you open up the web.config file which you will see the node with its value set to "WSS_Minimal" by default, literally you might know already why the sharepoint won't let you access some of its resources like list data etc. So if you do a search for keyword in this web.config file for "WSS_Minimal",the security policy section contains both minimal and medium security policy. Which points to each own xml policy file. If you want to adventure into the policy file and customize it, the words like minimal and medium will not stop you from doing silly things on this computer. So, suit yourself, try medium first before any drastic solutions.
2. When you deploy a webpart, we know that we can deploy it as a safe control and configure this assembly's CAS, or just put in in GAC(Global Assembly Cache,i.e. sytemdrive\windows\assembly) to give it much wider access to your system which won't be under control of your WSS policy control. This will solve most of your problem
3. If none of above works for you, you might start thinking give your assembly a full-trust , which means it can access all resources in your system and do whatever it wants to(basically what you or the hacker wants it to ). To do this, go to control panel->administrative tools->Microsoft .Net Framework 1.1/2.0 Configuration->Runtime Security Policy->increase assembly trust. then you will see a slider bar which lets you define different level of trust, suit yourself in this action , however, referring to previous failures made in step 1 and 2, I think you might want to go for full-trust anyway...

Any of above might solve your security /permission related exception thrown by sharepoint or .net framework according to individual case. Just bear in mind that CAS is the essential part that you can't avoid during sharepoint development.

1.