Recently, we came across a severe problem in production farm with the Content Types. I would like to explain the background of this problem first.

We have nice working feature for Content Types installation in production and test farms. We developed and deployed (using wsps) this SharePoint feature in Visual studio. We are using the publishing pages using page layouts and Content Types to help content editors to quickly publish the web pages. Unfortunately, some Content Types and site columns have been manually updated/added by some people in the production, so whenever I (developer) make some changes to the existing Content Types (using Visual Studio and feature activation/deactivation) , SharePoint removes one or two columns (during feature activation/deactivation) from Content Types; or the columns which have not been added in a best practice way. I think the best practice is to update Content Types using Visual Studio.

Now, I wish to ensure that site columns shouldn't get removed from Content Types upon feature activation/deactivation.

Note: Our feature for Content Type activation/deactivation doesn't hold any activation dependencies in the feature.xml

2 Answers 2


You should not use activate/deactive when updating Content Types (as you've noticed). For SP2010 you can use feature receiver upgrade stuff but for SP2007 one best practice is to add a new feature with a feature receiver that makes the upgrade using code.

  • Thanks for your reply! But what about the site columns which have been added manually and then added to the Content Types? Would you suggest me removing them via SP UI, and then adding again via Visual Studio? Jan 4, 2011 at 11:20
  • If you add/modify the columns of the CT's using feature receivers (in new features) then you don't have to deactivate/activate the old ones and you can let the manually added columns be as they are. Jan 4, 2011 at 11:30

There are two problems here. First, if you deploy content types with code you can't explicitly set the GUIDs, so you get different GUIDs on different farms (e.g. test, authoring, production). Now when you move content between farms GUIDs get out of sync., duplicate site columns appear, etc. - welcome to hell.

Second, if you deploy your content types with CAML everything is fine - you set the GUIDs and it is now consistent across farms... until someone changes something through the UI. Now the link to the XML in the 14 hive is gone and the CAML is instead in the tables in the content database. Next time you deploy it has no effect. So you start putting code in feature receivers, and we are back to the first problem.

There is no easy solution to this. The best way is probably to prohibit changes to the schema through the UI, or programmatically "re-ghost" them in the feature receiver, at the risk of deleting changes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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