Updating declarative XML content types

Thu, Sep 15, 2011 4-minute read

Becoming a SharePoint developer is always a journey - every new day you spend doing something, the more you learn. More often than not, the more “little subtleties” you uncover about the great wide SharePoint platform. I recently tripped over one such example. This “issue” is not new in SharePoint development - it certainly goes back as far as MOSS2007, but unless you’re actually doing it, it’s not something you’d instinctively just know.

Creating content types via XML Visual Studio

As soon as you start building SharePoint solutions of any real size and complexity, you’ll quickly learn that creating fields and content types via the UI, or SharePoint Designer, is not a great solution. For instance, there’s no supported way to move a SPD designed solution from e.g., Dev to Live - that is, with SPD, you design directly against live. This can be OK for initial deployments, but as soon as the system has data in and you need to start potentially breaking things, this is not a good place to be in. The alternative to this is develop Visual Studio solutions and features, which are deployable pretty much wherever you’d like. You can define fields and content types in XML, and when you’re finished, package it all up and deploy. Simple, right? Well, no, not necessarily - as I mentioned recently, this process is not without its bugs and issues.

I’ve deployed a few solutions in this way, and was (until today) singing the praises of deploying content types via XML, thinking how wonderful it was to have the flexibility to build in dev, test and then deploy (i.e. what you can’t do with SPD). And of course, if you make any changes, you can update your solution and hey presto, nice neat update.

Well, that’s all good in theory apart from the last bit - deploying changes to existing XML content types. - it’s not supported! (Well, you can do it, but any list content types created from the site content type won’t receive any of the changes, unless you blow away the list content type and recreate it, which is obviously a bit of a problem if you’ve actually got stuff in the system using that list content type.) This sums it up quite nicely:

Be aware that Content Type deployment via Features using declarative XML
doesn’t work with inheritance changes. For example, your content type ‘Letter’
is deployed via a Feature using XML. You use this content type in various
locations in your site collection. You add a new field to your content type
using XML and redeploy via the Feature. Your original content type that is used
in lists doesn’t change, however if you add the updated content type to a new
list it displays the new field.

Microsoft’s version is pretty succinct on the issue. Don’t do it!

So what are your options? Well, it’s not a new issue - some chaps as far back as SP2007 have discussed this, and even come up with some means (e.g., stsadm extensions) to try and do the update for you: ) I’m a bit nervous about those extensions though, as they seem an entirely brute force (i.e., compare old vs new and try and work out what should be done.) way of doing things.

I’m a bit baffled by MS’s opinion on this - they clearly say that to update provisioned content types you should do it through the UI (?! ugh.) or via code and the object model. I suppose it depends what sort of changes you want to make. If you’re just adding a field, then perhaps it’s not too bad. But for me it introduces all kinds of maintenance headaches. Should you update your solution so that the content type XML is up to date with the new field, so that if you ever rebuilt the system it would match? Should you deploy your updates to the content type as a feature, or just run it one time in a console app?

My particular issue is that I’m using the new Document Sets feature and due to aforementioned bug feature of the CT, the XMLDocuments I wanted to deploy didn’t deploy. I now want to redeploy the Document Set CT with the updates (and some extra columns to support new functionality), but I “can’t” do this via redeploying the XML Content TYpe. So my options are:

  1. Update the feature. Redeploy to site. Keep copy of all data in all libraries using the CT, blow them away, recreate and copy data back in. RISKY!
  2. Update the site content type via code. OK if the changes are trivial, I suppose.
  3. Update via UI - yuck.

I’m not decided yet… I *suppose* #2 is the way to go. I’m intrigued to know why, though, an update to XML Content Type can’t be pushed down to CTs that already inherit from it.