Ups and Downs of Content Type Creation Methods

Question

There are several places online I've read to only create content types in feature XML. However, the reason for this seems to be to keep the content type as deployed in a feature.

As I understand it, content types can be created in four different ways

• Web interface
• Client Object Model
• Server Object Model
• XML

The first two, web interface and client object model, have the disadvantage of disconnecting the content type that is being used from what is defined in the feature definition (if it is defined in a feature at all). But it seems to me server object model executed in a feature activated event handler is still 'as defined in a feature' and would not cause a problem.

So, is there a problems with creating a content type solely in the feature event receivers instead of in the features XML?

I don't think I'm inclined to do so, as I would prefer it be done in one place. But are there problems or benefits in declaring the content type in XML and then modifying it as needed in the event reciever?

---

Louis:

I'm not really looking for information for a specific scenario, but general information so I can make up my mind on what 'best practices' I'm going to use. With that in mind, this is what I've come up with so far: - the client object model doesn't allow the content type to be wrapped in a feature for deployment, so it's not looking like a good choice. - the web interface (I'm assuming) is just another client and uses the client object model, with the added down-side of not being able to place the changes in a code repository. - the server object model is good since it allows for feature creation and deployment and is code repository friendly. - the XML declaration method has the benefit of being the least hassle, but it is limited in that it can not do everything and has to be augmented with the server object model.

So I am leaning toward server object model. The only question I really have left is should I use XML declaration at all. What I'm lacking is an understanding of what (if anything) happens differently between the XML and a server object model code-only approach. This is further confounded by the XML approach not being a full approach in itself.

So I come back to the same question again (stated a bit differently). I've been reading that it is a 'bad' thing to disconnect the content types being used from the XML definition, but have not been able to find any solid reason why. It would seem to me that as long as the content types being used are as defined in features (that is, not modified by the web interface or client object model) everything should be fine -- but is this true? What benefit does a feature defined in XML have over one that is defined in server object model in a feature receiver? Are there any?

Again, I'm not looking for opinions or such, just information about how the two approaches are handled differently under the hood.

Answer 1

As you mention, declarative content types had issues in SP2007.

Since you mark your question as a SP2010 question, the story has changed.

In SP2010 we now have support for feature upgrade. Feature upgrade gives you the possibility to either declaratively or programmatically upgrade features, and hence get existing activated features (SPFeature) up to par with the installed features (SPFeatureDefinition). Declaratively you have some limited possibilities including re-applying manifests and for content types we can add fields to an existing content type and force the changes to existing list content types: AddContentTypeField

You still dont get around using the object model entirely when creating content types, since stuff like lookups and taxonomy fields (which inherits from lookup) still need to get hooked up with the right references in a feature receiver, but in general you shouldnt have to use the object model for creating or upgrading features in SP2010

For more info on Feature upgrade: SP2010 Feature upgrade kitt by Chris o´Brien

How to manage your Feature Lifecycle using Feature Versioning article in DIWUG magazine by me :-)

MSDN reference on Feature Upgrade

Answer 2

In many cases this is a matter of preference and in some cases you have to rely on one or the other method or even both.

For instance provisioning Managed Metadata Site Columns cannot be done using solely XML. Either you do a fully programmatic approach or a combination of CAML and code.

Answer 3

For me it depends on your scenario, you would want to use the OM if you dont know some properties when you are creating it. If you know everything about the content type to create the best way to go would be using the XML approach. I think its more organized and you dont have to write code for that.