I stumbled across a new post by Maurice Prather over at Bluedog Limited which I wanted to comment on here (and I’ve left a similar comment on his blog). His concern was with my post about setting up your virtual development environment. The issue was regarding the part around changing “WSS_Minimal” to “Full” in the web.config file. Like he mentioned in an earlier post, this isn’t required for debugging to work nor is it a recommended practice in your shop.
I personally use it in my own development spaces only but what I neglected to mention was that a) I have another VM which is setup with “WSS_Minimal” as the trust level and b) doesn’t have Visual Studio, etc. installed. I use this VM for testing Web Parts before I release anything to anyone for testing externally (either publically or to my clients development/testing environments). With this setup, I also have to setup the policies on Code Access Security for any Web Parts. This isn’t a trivial thing to do but it’s also neither rocket or science.
The point of my article was about getting a development environment up and I personally don't consider it lazyiness if your dev enviroment is running full trust. Yes, if that's *all* you do then it's being lazy and maybe I've set a bad example but let's be honest here, do you really want to go through the issue of creating the web.config entry for every single web part you create? (grant you, not every web part might need that but there’s probably something you need to do for most).
Another thing that I lean towards in this development environment is one of presentations and just rattling off a quick web part to test a technology spike. As an example, sometimes I need to quickly create a Web Part so I:
- Create a new Web Part project
- Write the minimal amount of code I need to get my spike results
- Install with the InstallAssemblies tool
I can have a working web part up in a minutes which for me is key when you're either showing someone something or just need a quick hit to figure something out. To spend time on CAS for a web part I’m going to throw away is probably too much time that I don’t want to waste (especially if someone else is paying for it). For me (and again, this is my preference) I would rather deal with security (and other SharePoint-y type stuff that can be fixed with configuration) in a test environment.
Having said all that basically you should read up on Code Access Security and Web Parts as there’s a lot out there and it’s important stuff so bottom line, don’t run as “Full” trust in web.config for your SharePoint environments.
One more thing that might make life easier (although I’m not sure yet). I finally got around to playing with CodeSmith that I picked up awhile ago. I’ve always seen it as a generation tool for creating your Data Access Layer (from a SQL or Access database) and I’m not one for code generation tools. There are some more advanced examples like the .NetTiers templates, which generates a fully commented and unit tested DAL from a database but one of the really cool thing you can use CodeSmith for is just generating repetitive code. I’ve always had to create things that are repetitive like strongly typed collections for business objects. It’s not a lot of work, but redundant and always the same thing. With CodeSmith you can get it to do the work for you (like a really uber-geeky macro). There’s also the ability to tie in a code-behind page with your template so it got me thinking that you might be able to do something like point a CodeSmith template at your Web Part (or a CAB file) and generate all the CAS entries for your web.config file automagically. Well, it’s just a theory and when I find some time to investigate I’ll see what can be done.
In any case, thanks Maurice for this important aspect of SharePoint development that often gets overlooked.
Note: In addition to Maurices resources on Code Access Security, Bamboo has an in-depth PDF document here on pretty much everything you need to know (including the complete set of permissions) but were afraid to ask about CAS and SharePoint.