Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 8 down vote accepted

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.

share|improve this answer
    
Never knew that you could specify the ContentTypeId in code in 2010! What about fields? –  James Love Jun 4 '11 at 12:13
    
Interesting with inherits. Could you put some words on your fears regarding Inherits? –  Anders Rask Jun 4 '11 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... –  Anders Rask Jun 4 '11 at 16:07
    
@Anders See [3] above - link to a blog post describing the inconsistent behavior of Inherits –  Rob Windsor Jun 4 '11 at 16:53
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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