SharePoint Content Type Cheat Sheet

Tuesday, February 15, 2011

SharePoint SharePoint 2010

Principle

Any application or solution built in SharePoint must use a custom content type over adding columns to lists. The only exception to this is one-off solutions that have no life-cycle, proof-of-concepts, etc.

Creating Content Types

Web UI. Not portable, POC only
C# or Declarative (XML). Must deploy these as Features

Rule

Do not chagne the base XML for a Content Type after deploying. The only exception to this rule is that you can re-deploy a modified Content Type definition only after completely removing it from the environment (either programatically or by hand).

Updating Content Types

Update and push down to child types

Web UI. Manual for each environment. Document steps required for repeatability.
Feature Upgrade. Preferred solution.
C#. If you created the content type through code you might want to go this route.

Create new modified Content Types and hide the old one. Not recommended but useful for legacy.

References

Agree or disagree?

3 Comments

Worth mentioning is that the preferred method of updating is to use Feature Upgrades. Saves you from creating just another feature.

Wictor - Tuesday, February 15, 2011 9:59:36 AM

@Wictor Thanks, I've added that as the preferred method for upgrades. For some reason it was absent from my mind when I wrote this.

Bil Simser - Tuesday, February 15, 2011 12:09:02 PM

We've periodically updated (added to) the custom content type XML we use on westernaustralia.com for years now with no major issues. Dirty but the additive change flows through automatically although our content type hierarchy is quite flat.

Michhes - Tuesday, February 15, 2011 6:12:38 PM

Comments have been disabled for this content.