I'm currently planning on how to package my Publishing content types in a WSP to make deployment in production easier. I came a cross the following choices 1- create a feature receiver and programmatically create the content type and its fields 2- use the elements.XML to provision the content types.

Now I feel that the elements.XML solution is more like a standard solution, although I think that the programmatic one is more maintainable since we have to package around 10 content types with a lot of fields inside.

So, from your experience what is the best option? also, what if we wanted to do some change to our content types, what is the option that is more upgrade friendly?

2 Answers 2


I have to disagree with James.

  1. The SPContentType in SharePoint 2010 has a new constructor that lets you specify the content type id.

  2. The addition of the Inherits attribute of the ContentType element makes the behavior of content types described in CAML inconsistent.

  3. Finally, the Feature upgrade mechanism is great if you are adding fields but it doesn't handle other situations so you are going to have to fall back to code anyway.

My suggestion is that you create all your fields and content types in code.

  • Never knew that you could specify the ContentTypeId in code in 2010! What about fields?
    – James Love
    Jun 4, 2011 at 12:13
  • Interesting with inherits. Could you put some words on your fears regarding Inherits? Jun 4, 2011 at 16:04
  • Regarding feature upgrade, you do have the option to put code in FeatureUpgrade event. Deleting fields will always be a challenge no matter what approach you take, I tend to hide the old CT and create a new one rather than deleting and hence loose data... Jun 4, 2011 at 16:07
  • @Anders See [3] above - link to a blog post describing the inconsistent behavior of Inherits Jun 4, 2011 at 16:53

Deploying content types via the elements.xml allows you to define content type Ids as well as your site column IDs (which you can't do via the API unless you use AddFieldAsXml) This makes life a lot easier later on in code, as the IDs will remain constant throughout your development lifecycle between environments.

With SharePoint 2010's Feature UpgradeActions, applying updates is relatively simple.

Packaging 10 content types with many FieldRefs sounds initially daunting in an XML file, but it is actually easer to keep it in the XML rather than the more verbose method of storing that provisioning information in many, many lines of code.

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.