Creating Custom Content Types for SharePoint using Visual Studio (or Notepad) and a few other tools...

calendarOct 26, 2007 · 5 min read · Content Types Features SharePoint  ·
Share on: linkedincopy

There are a number of ways of generating Custom Content Types for SharePoint, some more difficult than others.  One of the easiest ways is to create your own using the SharePoint GUI interface via a web browser, however while a nice 'point and click' approach, there is no easy way to extract the resultant custom columns and content types for use on another farm.

At the other end of the spectrum, you can hand code the required XML from scratch and generate the features for installation.  This has the advantage that you can re-use the features you generate, but the fairly obvious disadvantage of having to hand-craft XML for use in the features.

There are also a couple of 'middle of the road' approaches, one of which I'm going to comment upon, the other of which is what I am going to briefly discuss here.

The first 'middle of the road' approach uses the Codeplex SharePoint 2007 Content Type Viewer, details of the use of which can be found at http://dhunter-thinkingoutaloud.blogspot.com/2007/06/creating-content-types-with-content.html - I do however have a problem with the approach outlined and I'll explain why:

The Content Types Viewer is a very useful utility that allows you to extract information about content types from a running instance of SharePoint, even those created via the GUI.  The utility provides you with the Fields (columns), the FieldRefs (for specifying in the content type) and the schema for the content type.

Using it in the way described in the above link, the user would copy the Fields data from the Content Types Viewer and generate a feature to install these fields, then create a content type feature containing the information from the FieldsRefs.

The problem I have with this approach is that none of the information from the schema is used within the content type.  I'll give and example as to why this is bad:

  • Create a custom content type; it doesn't matter what columns this contains as long as it contains at least one column that is a choice.  Fill in a number of choices for this column.
  • Create a list associated with your custom content type.
  • Extract the fields and content type using the Content Types Viewer as instructed.
  • Copy the fields and content type features to another farm, install and activate them.
  • Recreate your list using the GUI on your new farm and associate it with your content type.
  • Try to create a new entry in the list.
  • You should see that the choice column(s) you contain no data!

The reason this happens is that the choice information you supplied for your custom content type is contained within the schema for that content type.

To rectify the situation, do the following:

  • Save the list on your original farm as a template (.stp).
  • Copy this template to your new farm and upload it into the list template gallery.
  • Create a new instance of your list from the template.
  • Try to create a new entry in the list and your content type magically now contains the choice data you input on the original farm.

This happens because the schema information is contained within the list template file created on the original farm.  You can test this hypothesis by extracting the manifest.xml from the .stp file you created and looking at it - you should see your choices listed within XML fields.

While this works quite happily if you only ever want to transplant your custom content type/list combination to another farm, however if anyone creates a list from scratch and associates it with the custom content type on the new farm the list will not be able to function properly.

A better approach is to use the Content Types Viewer, but also include the required information from the schema.  While this involves a little more than 'cut and paste' from the Content Types Viewer, it does at least provide a complete content type for transplant to another farm.

Most of the information from the schema should be transplanted into the Fields feature, with the content type feature remaining the same.  A number of fields from the schema should not be transplanted as these cause errors when attempting to install/activate the feature.  These include:

  • Version
  • Customization
  • Aggregation

A few notes:

  • Generally you should use SourceID=http://schemas.microsoft.com/sharepoint/v3 in your fields feature.
  • There may be problems associated with referencing other fields for (for example) a calculation field as these typically utilise a GUID to identify the column you wish to extract data from.  If you are referencing columns within the same content type, you can simply use the column name and dispense with the GUID.  If you wish to access information from another list you have a problem as the GUID for the list will be generated dynamically when the list is created.  If you wish to do this you need to create the lists you wish to reference first and extract the list IDs for use in your feature.  An alternative (in particular if you wish to wrap your features up into a SharePoint Solution) is to write a feature receiver to dynamically add the appropriate columns with the correct GUIDs to your feature at activation.

I aim to discuss creating field and content type feature creating in more detail in a future post.