SharePoint Content Type Lifecycle Management

That’s just a fancy term for updating content types via feature upgrades.

In SharePoint 2010, there’s a new UpgradeActions element and a handy new AddContentTypeField element as well.

There are a couple of good blog posts that discuss this topic and an unusually useful MSDN article on the topic of application lifecycle management in SharePoint 2010.  These more than cover the topic of adding new fields to existing content types via upgrades.

One key point from this article is the following section of text:

This section describes at a high level how you can put these feature-versioning and upgrading capabilities to work. When you create a new version of a feature that is already deployed on a large SharePoint 2010 farm, you must consider two different scenarios: what happens when the feature is activated on a new site and what happens on sites where the feature already exists. When you add new content to the feature, you must first update all of the existing definitions and include instructions for upgrading the feature where it is already deployed.

For example, perhaps you have developed a content type to which you must add a custom site column named City. You do this in the following way:

1. Add a new element file to the feature. This element file defines the new site column and modifies the Feature.xml file to include the element file.
2. Update the existing definition of the content type in the existing feature element file. This update will apply to all sites where the feature is newly deployed and activated.
3. Define the required upgrade actions for the existing sites. In this case, you must ensure that the newly added element file for the additional site column is deployed and that the new site column is associated with the existing content types. To achieve these two objectives, you add the ApplyFeatureManifests and the AddContentTypeField upgrade actions to your Feature.xml file.

It would seem that this would be a great mechanism for managing your metadata upgrades.  As bullet number 2 implies, one simply adds the new field to your existing element manifest file for new installs and add a new element manifest file plus a AddContentTypeField element to your feature XML for upgrades.

After trying this out for almost two days now, I can say with some certainty that this does not work as documented or designed.  You cannot add the field to both your original element manifest XML (for new installs) and to a separate element manifest file for upgrades.  It does not work.  After performing an upgrade, the symptom is that the field does not get pushed down to the list level content types that inherit from the site level content type.  If you go to add the field manually, you will see the field appear twice:

You can see the result of two passes of testing here.  At the site level, the content type is fine and dandy; it’s only at the list level where things go wrong.  Obviously, this is less than ideal.  I tried numerous variations of feature setup to see if I could get it to work without code and none of them worked.

Ultimately, the solution that worked for me was to add a CustomUpgradeAction as well in addition to the AddContentTypeField.

The upgrade action has the following code in it:

It’s a lot of redundancy, but ultimately, the only way I could get the upgrade to work with the field in both the original element manifest (desired for new installs) and in a new element manifest for upgrades.  I should note that if you do NOT add the field to the original element manifest, everything works as documented.  But this is a less desirable scenario as it means that every clean install would also require all of the updates to be run afterwards.

Here is the full listing

My feature.xml file:

A snippet of the original element manifest with the new field added to the content type for new deployments:

The new upgrade element manifest:

And the custom feature receiver (with portions omitted):