I've been researching a few different ways to create content types and I recently discovered that you can use the Object Model to do this. All of the examples I have found online typically use XML files to create content types.

I'm curious if anyone knows of some commonly accepted pros and cons of using Feature based XML files versus using the Object Model to create content types?

  • 1
    What version of the product are you using? Story is different for SP2010... Nov 17, 2011 at 21:12
  • I am using SP 2010 Nov 17, 2011 at 21:35
  • Will you still use XML approach on creating hundreds of content types per site collection?
    – user11703
    Oct 30, 2012 at 16:13

3 Answers 3


One of the problems with content types (there are quite a few!) is that the design with site and list content types works very poorly with the declarative (XML) approach.

If you just update your Content Type manifest and re-install the feature new content types will be affected, but not all the list content types already "instantiated" from the site content type.

This is the main reason why people choose the code approach, since this effectively "unghosts" the content types placing all logic in the content database like the list content types.

In SharePoint 2010 the story is a bit better than in SP2007 though, since we have feature upgrade. Feature upgrade, as Jim mentions, gives you the possibility to add new manifest code to be run, and more importantly the AddContentTypeField makes it possible to add fields to existing content type, specifying if the changes must be pushed down through the list content types. More advanced scenarios can be handled in feature upgrade code. More on feature upgrade here.

In SP2007 i always took the code approach, and lots of my colleagues still do (some even outside of feature framework, calling custom code that reads XML definitions). However since feature upgrade addresses some of the upgrade issues with Content Types, i have fallen back to using XML. There are disadvantages with the XML approach with poor documentation on specific attributes, especially regarding taxonomy fields (read this article by Ari Bakker along with some of my comments at the bottom regarding DisplaceOnUpgrade and Override.

I often only create the most basic content types in XML and publish them to the CT hub. These could typically be sealed on high level and then be modifiable on the more specific levels.

I wrote up a longer answer some time ago on Stack Overflow: https://stackoverflow.com/questions/446451/sharepoint-what-happens-to-lists-based-on-content-type-when-content-type-is-upd


From the point of view of an experienced developer there is no major difference but there are points to consider.

Code approach:

  • More friendly for new developers, cause VS environment provides good features for investigating new API
  • You can debug it step by step, comment and use Watch tools, in comparison with XML where you just see the result
  • Before XML approach was not well documented, and certain properties puzzled developers


As for me, I prefer the XML approach.


This might end up as a 'whatever floats your boat' kinda question. I will add though, that whatever you choose, make sure it's consistent throughout the entire solution.

Remember that creating Content Types programmatically is done at Feature Activated level, which is after Feature XML is processed, so if you're provisioning Page Layouts, you'll need to ensure that you do the content types in a separate feature and that's activated before the one with your modules in.

As @default mentioned as I was typing this, you can step through code and have intellisense documentation of code, to the level you don't in XML. You could argue that with code, you have absolute control over every single thing that's happening when you do it via code.

Do also consider how you upgrade your content types if you write Feature Upgrades. This is easier when everything is done in XML, and might be trickier if done through code.

  • Just out of curiosity, which method do you typically use? Nov 17, 2011 at 19:34
  • 1
    XML, because it's less 'wordy', fewer lines needed to do the same task, and requires less maintanence (write once, forget about it), and should be easier to upgrade. I got a feeling Anders Rask goes for code though...
    – James Love
    Nov 17, 2011 at 19:38
  • 1
    Ended up going the XML route (even through it feels icky). Thanks! Nov 21, 2011 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.