When using the XmlAnyElementAttribute to serialize/deserialize an Xml file in Silverlight, you’ll come up against a minor problem. the MSDN documentation states: Specifies that the member (a field that returns an array of XmlElement or XmlNode objects) contains objects that represent any XML element that has no corresponding member in the object being serialized or deserialized. However, in SilverLight you don’t have wither of these objects, you’re restricted to what’s available via the System.Xml.Linq namespace Luckily the XElement object does the job, so code like this will work:   ...

I’ve been following a few forum posts about modifying the built-in navigation providers in SharePoint and thought I’d knock up a quick post explaining, step-by-step how this can be done. Unfortunately, the documentation at MSDN is a bit cryptic (Although you’ll see by the end of this article that it makes perfect sense!) As usual, I won’t get into details about creating and deploying features. WSPBuilder is your man. (Although I’m finding SPVisualDev to be a handy wee tool as well these days) So what’s the plan then? On the default master page, you’ll see code...

I thought I’d have a read through the technical preview docs for SP2010 and came up against this problem: I’ve seen this problem a few times before when tying to access .CHM files. It often happens when you download SDK documentation from the web. (Unsurprisingly since it’s a security feature designed to prevent downloaded content from causing mayhem on your PC!) To fix it: Find the file that you’re trying to view, in my case: SPPT2010TP.CHM Right click then select Properties: Hit the Unblock button...

Ever wanted to be read the Status text displayed on WrkStat.aspx programmatically so that you can make use of it elsewhere? No? Can’t blame you! However, let’s say that you do fancy a bit of masochism. Here’s how it works: The status value is stored in a field of type SPFieldWorkflowStatus. Generally this field has the same display name as your workflow although it’s internal name will be different. Getting the internal name is a pain, for some bizarre reason Microsoft decided to expose this as an internal property rather than public. (See SPWorkflowAssociation.InternalNameStatusField). After...

When developing an application based on SharePoint, a lot of the work goes into packaging and deployment. If you’re working as part of a team this becomes an even bigger problem since you need to be sure that your code can be deployed to each developers machine without causing mayhem and requiring a disproportionate amount of effort (quite literally two steps forward and three steps back!) As it stands at the moment, CAML is a grand idea but it doesn’t go far enough when it comes to packaging complex solutions. It’s my aim to fill in the blanks, making...