A couple of weeks ago Chris O’Brien – fellow MVP wrote an article on the research of the SharePoint BLOB cache he has done. During that research he has experienced some issues with some of the files not being cached properly on the client causing the browser to request the file every single time. As I’m working with Web Content Management solutions on SharePoint a lot, it definitely took my attention.
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.