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”
Okay, so I’m not a huge fan of the out-of-box publishing layouts. I’ll be honest – I reckon that there should be about half of the layouts, and I don’t like the ‘Welcome Page’ as a description. ‘Generic Page’ perhaps?
Anyway, some of them have pretty cacky layouts, often with Summary Links built into the page (why? Can’t I just add a web part?) – but as a rule, they keep the left hand navigation for the site. This is good – users get confused when their navigation isn’t how they expect.
New WSS Pages, however, do not keep the left hand navigation.
This has led to more than one customer asking “where has my left hand nav gone?” Not an unreasonable question – after all, did someone think that users wouldn’t need standard navigation in team site pages? Don’t get me wrong, I like that you can get rid of the left navigation menu if you want – but I think this will be the exception, not the rule.
You can get the left navigation back using SharePoint Designer (and some cynics might suggest it’s a ploy to set SPD licenses, though I don’t think so). However, I shouldn’t have to! Can’t I have a couple of out-of-box layouts that are like, well, the one used in Default.aspx on my team sites? Is there a Codeplex project for such a thing, maybe?
Even better would be if Default.aspx existed inside a library like any newly created pages I build are. I don’t like that it is separate to the other pages in a WSS3 site.
This is a pretty weird error. I was doing content roll-up of Announcements lists, to give a unified news channel for our intranet. Naturally, I decided to do this using the Content Query Web Part. I added one, and selected that I wanted to query for the contents of Announcements lists. As I like RSS feeds, I enabled one, and I added it to my favorite feed-reader.
It worked – but the links to the announcements themselves didn’t work. The short summary is that is that it appears RSS feeds from Content Query Web Parts don’t work when you query for certain types of list. Continue reading “Error: CQWP – RSS feed of non-documents doesn't work”
Like many people, one of the things I found a little hard to adjust to was not using folders in SharePoint. I mean, you can, and they do have their place, but metadata and views is much more useful. However, now when I go out to customers I notice that a lot of them have a lot of difficulty letting go of using folders for everything. Continue reading “Yes, Folders in SharePoint do suck”