Getting levels of the SharePoint Heirarchy and their Exceptions

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:

try
{
    //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.

Advertisements
Getting levels of the SharePoint Heirarchy and their Exceptions

Curious case of Microsoft.Office.Server.ServerContext.Current

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”

Curious case of Microsoft.Office.Server.ServerContext.Current

Observations on SharePoint 2007's irritating Audit

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”

Observations on SharePoint 2007's irritating Audit

'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater

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.

'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater

UpdateListItems Web Service fails when using item level permissions

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' />
<Field Name='FileRef'>http://site/library/folder1/folder2/mydoc.pdf</Field>
<Field Name='ContentType'>Invoice</Field>
<Field Name='InvoiceNumber'>12345</Field>
</Method>
Under normal circumstances, the above XML works just fine. However, if you enable fine grained permissions [Item Level Permissions] in a document library it will break with a permissions related error (even though you have permissions to perform the action!) Continue reading “UpdateListItems Web Service fails when using item level permissions”
UpdateListItems Web Service fails when using item level permissions