Nick Hadlee's Blog on SharePoint and Other Occasional Rants…

Making Features that Deploy Content Types Compatible with the Content Type Hub
January 8, 2011, 10:55 am
Filed under: 2010, Content Types, Development, Tips & Tricks

* Update 15 May 2010 – this isn’t a problem! After some feedback from Chak’s and some retesting I’m happy to say that CAML features and the content type publishing hub work together fine. I can’t reproduce the problem and neither can Paul so I’m going to park this as a SharePoint X-File. I’d recommend you don’t use the method below unless you have a good reason to mix OM/CAML features in your deployment.

Paul Grimley wrote a post a while ago which highlighted a problem * with the content type publishing capability of SharePoint 2010. The particular problem highlighted by Paul’s post is the inability for content types to be published by the content type hub if they have been deployed by declarative CAML in a feature…seriously!

So we have two components of SharePoint 2010 – feature based content types and the content type hub – which are incompatible with each other. In my opinion there are lots of reasons you may want to deploy content types via features including:

  • Portability – deploying artefacts such as content types between environments such as DEVELOPMENT, UAT and PRODUCTION is much easier when they are wrapped up in a feature
  • Visual Studio 2010 support – you can leverage the content type SPI’s (SharePoint Project Item) for creating content types in your solution which provides a nice interface for selecting its parent etc etc
  • Readability – CAML based features are (sort of) human readable which sometimes makes it a lot easier to determine what is happening within the feature by reading the XML than the source code
  • Best Practice – haven’t we been told time and time again that it’s a best practice to deploy customisations to SharePoint via features and solutions?

So there are lots of reasons why we want to use features but we also want to use the content type hub, what are our options? After a bit of trial and error I came up with the following pattern that seems to work well albeit with a few limitations.

The Workaround

The API for 2010 provides a new constructor for the SPContentType class that lets us create a content type via the object model with a specified ID. This is a important change from the 2007 API which will be the basis of the workaround:

  • Create a base content type using the Object Model:
 string baseContentTypeId = "0x010100ee23a9df11631348b5a5ac7fdfd66b49";
SPContentTypeId contentTypeId = new SPContentTypeId(baseContentTypeId); SPContentType baseContentType = null;
baseContentType = contentTypes[contentTypeId];

if (baseContentType == null) {
	baseContentType = new SPContentType(contentTypeId, contentTypes, "Base Content Type Publishing");
  • Any content types that should be publishable via the content type hub must be a descendant of this base content type (either a child, grand child etc)
<!-- Parent ContentType: Base Content Type Publishing (0x010100EE23A9DF11631348B5A5AC7FDFD66B49) -->
<contenttype id="0x010100EE23A9DF11631348B5A5AC7FDFD66B4900e54d81511bac4ad0837dd2ca3fb228e7" version="0" inherits="TRUE" description="A feature based Content Type that is publishable via the Content Type Hub" group="Custom Content Types" name="Base Document Content Type" />

My preference is to create the base content type via a ‘pre-requisite’ feature and then create a separate feature with the CAML based content types which will be dependent on this base content type feature. So far I’ve tested this ‘pattern’ with the following results:

  • These CAML based content types are disconnected from the features XML upon creation. This means any updates to the feature will not affect the content types. Updates to the published content types can be made by forcefully deactivating/reactivating the features but this is a risky operation as you might not know what has happened to the content types once they have been published.
  • If the attribute Overwrite=”TRUE” is included in either the content type or a field used by the content type the content type it won’t be published. It doesnt matter if the content type is a descendant of your base (publishable) content type or not it will never be published if you use the overwrite attribute.
  • These content types can be updated via the feature upgrade framework.

Unfortunately there are more than just a few things in SharePoint that you expect to work a certain way, or just work, that don’t. I love the platform but occasionally these “it almost works” moments can be pretty frustrating! If you have any feedback on this workaround I’d be keen to hear from you.

7 Comments so far
Leave a comment

Thanks for sharing Nick, its a pleasure to know there’s others in the community who are as keen to help resolve these frustrating shortfalls. Cheers Paul

Comment by Paul Grimley

[…] content types which allows you to specify the SPContentTypeId for the new content type. Visit Nick’s blog post for more info on this. You can also script the creation of content types using PowerShell, which is […]

Pingback by Content Type Hub FAQ and Limitations - MSDN Blogs

Thanks for this Nick, worked a treat for us.

Comment by Bryce Telford

great post, Nick. passed it along to my team as we build out some of this kind of automation in our migration platform

Comment by Christian Buckley

[…] unless you have learnt through living the pain of things like content type definitions in declarative CAML, SharePoint buildings blocks are difficult to maintain/change over time. SharePoint suffers from a […]

Pingback by CleverWorkarounds » The facets of collaboration part 5: It’s all Gen-Y’s fault – or is it?

Thanks for the article. I just wanted to make sure I understood. I made a deployment solution that builds lists, content types, and site columns, these have ball been created in elements.xml and then added to a feature and deployed to sharepoint site. Our project utilizing this site is using the content hub and we are getting all sorts of errors. Since I have created these content types declaratively, could that be a source of the issue? thanks, shaun.

Comment by shaun cline

Sorry for the late reply Shaun. It depends what sort of errors you are getting. I have found that the content type hub is much less forgiving of deployment issues (e.g. site columns that have reserved names etc). Maybe check the content type hub error log and see if that gives you some clues to the problem.

Comment by nickhadlee

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: