Thursday, November 4, 2010

SharePoint 2010 Custom Content Types and Fields Gotchas

If you have existing custom fields and custom content types that were created and deployed to MOSS 2007 successfully, and now you want to deploy them into SharePoint 2010, there may be a few things that'll surprise you. I went through a lot of pains to get it done successfully and the following is maybe a subset of all the gotchas out there.

Custom fields and content types are typically deployed in a wsp package and then activated via feature. Theoretically there should not be a problem to take such a wsp and deploy directly into SP 2010. However, there are some small changes (and bugs also?) in how SP 2010 handles fields and content types. The following were experienced on SP 2010 with August 2010 CU.
  1. Your content type xml definition contains comments between the tag, which you often do, as it's a good practice to explain what the fields included are and where they comes from. Then after a successful deployment, the Manage Content Type page shows none of the fields included in for the content type (Site Actions -> Site Settings -> Site Content types -> (select the content type, _layouts/ManageContentType.aspx). Looks to me like the code that reads the xml definition doesn't exclude comments node. Huh, Microsoft?

  2. Overwrite attribute. This behaves differently now, as detailed in this blog. Bottomline is, set this to try in development. Otherwise you can't deploy and then activate the feature with updated XMLs if a previous deployment failed and left phantom pieces in the farm.

  3. Inherits attribute. By default in SP 2010 a custom content type only has the fields defined in its node, unless Inherits="TRUE". This is a change of the default behavior from WSS 3.0.

  4. SourceID attribute. This specifies the schema http://schemas.microsoft.com/sharepoint/v3. Not sure what I was thinking, maybe just wanted to be cool, I changed this to http://schemas.microsoft.com/sharepoint/v4. And it caused some weird errors logged (Can't find the XML schema definition or something?). I definitely need to read up on what the differences between the two schemas. It appears that the majority of the schema definitions that SP 2010 uses is still in v3. So leave the SourceID value as v3.
I still have not quite figured out how to completely clean up a failed deployment or retraction, which may leave behind field defs or content type defs that are nowhere to be found in the UI, database tables, and API (SPWeb.Fields, SPWeb.ContentTypes), but nontheless lurks around and prevent activating the updated feature (Log shows exception that the ID already exists, or can't overwrite etc). People suggests to change the GUIDs of the feature, fields, or content types to get around the issue but it's not always practical.

1 comment:

Brian Cameron said...

I am very pleased to find this blog. I want to thank for your time for this wonderful read!!! Keep Sharing, I'll surely be looking for more.