Best way to package publishing content types

Question

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?

Answer 1

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.

Answer 2

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.