Something that I have to do time and again is get some element of SharePoint’s heirarchy, such as a site collection, site, list or item. This is pretty typical – that’s why we all use
USING to ensure proper disposal of SPSites and SPWebs, right? But what happens if the thing you’re after isn’t there? What exception get’s thrown? Well, this should be pretty clear:
//FileNotFoundException if doesn't exist
using (SPSite site = new SPSite(siteGuid))
//FileNotFoundException if doesn't exist
using (SPWeb web = site.OpenWeb(webGuid))
//SPException if doesn't exist
SPList list = web.Lists[listGuid];
//ArgumentException if doesn't exist
SPListItem item = list.GetItemByUniqueId(itemGuid);
catch (System.IO.FileNotFoundException fileEx2)
// Site or Site Collection Not Found
catch (SPException spEx2)
// List not found
catch (ArgumentException argEx2)
// Item not found
Hopefully that might prove useful to someone – and a good reminder for me.
So, this is the weirdest bug I’ve seen in quite some time. I’d inherited some code, which includes a settings page in the _layouts directory. It’s a pretty normal page – nothing particularly bad about it, and it seemed to work nicely. Then I received a call about an error with it:
Now, here is the weird thing. When I started to examine it, I tried to replicate the problem. And I realised that the page worked when I accessed it from the server, but threw an ArgumentNullException when I accessed it from a client.
Yes, you read that right. What machine you browsed to the page on mattered. The browsers were the same. The code worked when viewed on the server, and failed when viewed from the client. When I eventually fixed it, I swapped between the broken and fixed code a few times to prove it – this really was the behaviour! Continue reading “Curious case of Microsoft.Office.Server.ServerContext.Current”
Auditing with SharePoint 2007 is something that I’ve managed to avoid playing with until our current project. Frankly, this has mainly been because the user interface for audit details is inadequate out of the box. Most other systems, you just go to a page, and see what happened to that item.
Anyway now that I’ve started to take a look at it in more detail, I notice a few other minor problems with it… Continue reading “Observations on SharePoint 2007's irritating Audit”
It’s well known, but mostly to remind myself – if you’ve got a web part that causes problem on a page (like the yellow screen of death) and you want to remove it, add the following to your url:
Takes you to the Web Part Maintenance Page. I can never remember the bit you add to the URL
We test our applications often using ‘RunAs’ to run Internet Explorer under a different session. I know that SharePoint allows you to ‘Log in as a different user’ but it doesn’t always work that well for us (i.e. you log in repeatedly and it might let you in).
One of my colleagues was trying to edit a document logged into Windows as one user, but running his IE session at a different user. Clicking on the document opened it Word in IE – despite that the Library should try and open documents in their client application. Trying to edit the document he got the message:
‘Edit Document’ requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.
This is the same message as mentioned in KB833714, but a different cause. When I tried editing the same action but as the user he was logged into Windows as it worked fine.
This tip come from one of my colleagues, but it’s a good ‘un:
For those of you familiar with the Lists.asmx web service in SharePoint, you’ll know that the UpdateListItems() method allows you to apply metadata to a list item. The following XML provides a simple example of how I’ve been using it so far….
<Method ID='1' Cmd='Update'>
<Field Name='ID' />
So after having had the discs sat on my desk for months, I finally had a go at installing ForeFront on a VM. Here are my first impressions. Continue reading “First impressions of Forefront for SharePoint 2007”