YASPQ

I live and breath computers. Each and every day, for 12-16 hours a day, I sit in front of a computer spitting out various artifacts (mostly Internet Explorer/Firefox history links, but the occasional piece of code, application, document, or architecture that makes some kind of sense). Here's Yet Another SharePoint Quirk (YASPQ) that make me loathe that collaboration environment we all know and love.

Security. Love it or hate it, it's all around us. After all, without it everthing would be well, unsecure. SharePoint and Web Parts (and the .NET Framework to a lesser extent) has a big tie-in with security. Writing Web Parts is pretty straight forward however you'll run into a few security hurdles if:

• You want to reference other assemblies in your solution (things like domain objects or data access layers or the recently released Enterprise Library of application blocks, *very cool* and probably deserves a blog entry of it's own on incorporating them into SharePoint Web Parts so stay tuned)
• You want to reference the SharePoint object model (what else would a SharePoint Web Part do?)
• You want to make external calls to services like external Web Services or access sites using something like the WebClient or WebRequest classes.

Just spitting out HTML in your Web Part is easy. Talking to the SharePoint Object Model (which you'll want to do if you want to display SharePoint information like lists of sites, document library info, etc.) is a little more tricky but can be easily fixed by changing the trust level to WSS_Medium. Talking to other assemblies can easily be accomplished by adding the [assembly: AllowPartiallyTrustedCallers()] which shouldn't be a concern (although it *could* open your assembly up to attacks from that yet to be created .NET managed virus).

The three options you get with developing SharePoint Web Parts are evil, but balanced in a kind of masochistic way (much like writing Web Parts from scratch which I can now say I can do in my sleep and usually do).

1. Increase the trust level of the entire virtual server. Best option to keep your development cycle happy (compile directly to the BIN directory or have a NAnt script drop it there for you) and no IISRESET required. Least secure though and affects all assemblies on the virtual server.
2. Toss your Web Parts into the GAC. Less secure but easy to implement. Not a great development option though as you have to do an IISRESET each time you update the Web Part.
3. Create a custom policy file. Talk about complicated (no less than 5 steps to implement this and a bugger to get it right if you don't know where all the files are located on the server). The most secure and basically the most flexible as you can tune the security to the Web Part itself. However I've never seen any commercial, freeware, or otherwise Web Parts ship with a policy file or install one.

Anyways, a few options and definately something you should be aware of. Developing can be easy (and unsecure) and you can leave the heavy lifting up to consumers if you're creating Web Parts for others. In-house Web Parts *should* go through the motions and create and implement custom policy files so you can co-exist nicely with a locked down portal. You just need to do a little more legwork on these. Here are a few resources to get you more info:

Microsoft Windows SharePoint Services and Code Access Security
Creating Web Parts that Call Services
SharePoint, Code Access Security and SmartPart

PS I notice while I'm blogging on the .Text website my cursor is updating with each character I type and pausing from time to time. Must be something in the control doing an autosave of the blog, but it's damn annoying!