For quite some time I have been busy with trying to increase my productivity while working on SharePoint solutions. In the last two years I helped design a couple of tools and developed a few of them myself: all that to simplify the most common tasks and be able to focus on the solution-specific things. Recently I have focused on code generation: based on the information already present either in SharePoint or in your solution generate source code. You can see a part of the results of my efforts in Imtech Fields Explorer: generating wrapper classes and Page Layouts. What I’ve learned is that generating source code with code can get really complex. But just recently I’ve found a simpler way to get the things done: introducing Imtech SharePoint Templates for CodeSmith.
While working with SharePoint I have stumbled upon quite some inconveniences. Most of the time they were in methods that you don’t use that often, and when you do, you expect them to do something else than they actually do. I probably haven’t worked on a single SharePoint project where I wasn’t instantiating sites. So I was quite surprised when I found out that even something as simple as SPSite.OpenWeb doesn’t always do what you would it expect it to.
Back in October last year I started working with programmatically provisioning Web Part instances. The challenging part was that the assemblies containing the Web Parts’ code were located in the bin directory of the target Web Application. The custom STSADM command I was using for that purpose wasn’t able to resolve the Web Part type. Back then I have found a way to deal with it which I though was a working solution. Unfortunately: just last week I have stumbled upon the same situation: again.
According to the Windows SharePoint Services (WSS) v3 SDK the SPWeb.EnsureUser(String) method is all you need while programmatically working with users. Using nothing more than the login name it checks for you whether the particular user exists in the current web and adds it if required. Within a single line of code it retrieves for you a proper reference to a user no matter the membership/role provider. While it’s really that simple while working in the scope of your SharePoint Web Application, things get slightly more challenging when used in combination with a custom code outside of the HttpContext.
Recently, while working on a SharePoint solution I have rediscovered the SPUrlExpressionBuilder class – one of the many hidden gems of SharePoint 2007. After some research it turned out to be more than the URL tokenizer we know from WSSv3.