Issues while migrating Content Type from SP 2007 to SP2010

  • Makale

Content Types have been an integral part of SharePoint and I have seen some issues being faced while migrating the content types from SharePoint 2007 to SharePoint 2010.

Here i would like to mention about some of the issues I have faced during the migration of some custom content types which were being deployed using features from SP2007 to SP2010 environment.

The two common exceptions i have noticed are:

Case 1: The element of type 'ContentType' for feature 'xyzContentType' (id: xxxx-xxx-xxx-....) threw an exception during activation: The local device name is already in use. (Exception from HRESULT: 0x80070055)

Feature Activation: Threw an exception, attempting to roll back.  Feature 'xyzContentType' (ID: 'xxxx-xxx-xxxx.....').  Exception: Microsoft.SharePoint.SPException: The local device name is already in use. (Exception from HRESULT: 0x80070055) System.Runtime.InteropServices.COMException (0x80070055): The local device name is already in use. (Exception from HRESULT: 0x80070055)   
 at Microsoft.SharePoint.Library.SPRequestInternalClass.ThrowError(Int32 dwErr)   
 at Microsoft.SharePoint.Library.SPRequest.ThrowError(Int32 dwErr)     --- End of inner exception stack trace ---   
 at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionFieldsAndContentTypes(SPFeaturePropertyCollection props, SPSite site, SPWeb web, Boolean fForce)   
 at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionElements(SPFeaturePropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, Boolean fForce)   
 at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, Boolean fForce)

Case 2: Unable to locate the xml-definition for CType with SPContentTypeId '0x010100C568DB52D9D0A14........', exception: Microsoft.SharePoint.SPException: Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))  System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))   
 at Microsoft.SharePoint.Library.SPRequestInternalClass.GetGlobalContentTypeXml(String bstrUrl, Int32 type, UInt32 lcid, Object varIdBytes)   
 at Microsoft.SharePoint.Library.SPRequest.GetGlobalContentTypeXml(String bstrUrl, Int32 type, UInt32 lcid, Object varIdBytes)     -
 -- End of inner exception stack trace ---   
 at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)   
 at Microsoft.SharePoint.Library.SPRequest.GetGlobalContentTypeXml(String bstrUrl, Int32 type, UInt32 lcid, Object varIdBytes)   
 at Microsoft.SharePoint.SPContentTypeCollection.FillCollection(SPRequest req, SqlDataReader rdr, Boolean openWeb)

The exceptions by themselves are pretty clear and tell us the exact problem. But getting them resolved sometimes is a little tricky.

In the Case 1 scenario, it is obvious that the message says, the content type already exists. This may be because you had a feature in SP2007 that deploys the content type and after migration to SP2010 you are trying to deploy the same feature again. A look at the method "SPElementDefinitionCollection.ProvisionFieldsAndContentTypes()" gives us some idea. We can add the attribute "Overwrite=" TRUE " to the content type definition xml and deploy again.The "unable to locate the xml-definition for CType... " exception is also likely to be resolved by adding the Overwrite=True attribue and if feature gets redeployed succesfully.

But in somecases this might still not resolve the issue. The reason in my case was a mismatch in the folder paths to the content type elements.xml file. i.e. in SP2007 code the path might have been "Features\CompanyName\MyContentType\Elements.xml". But in SP2010 case, (since i have used the WSP import functionality provided by sharepoint to import the SP2007 package and modify it accordingly) the path was different like "Features\CompanyName\ModuleName\MyContentType\Elements.xml"

A look at the method "SPRequest.GetGlobalContentTypeXml()" shows that the relative path to the element manifest file is considered in order to locate the definition file. But since the old and new paths are different, all the page layouts or lists etc which used the content type are still unable to locate the content type xml file.

Resolution: If you are upgrading to SP2010 and if you notice a difference in the relative paths, then change the new path to match the old one exactly. This will ensure that all the previous items that were dependent on the content type function properly without any furthur change. If you want to go ahead with the new relative path, then ensure that before migration you have deactivated the feature that has content type properly and have removed the association to all the lists, pagelayouts etc that use this content type. After migration and upgrading, you can associate them back (Note: I have not tried the second approach)

After you have used the above resolution steps of choice, you may have to update the Content Type as well. The following piece of code shows how to do it:

 foreach (SPWeb w in site.AllWebs)
 {
 SPContentType contType = w.ContentTypes["ContentTypeName"];
 if(contType != null)
  contType.Update(true);
 }

Comments

  • Anonymous
    November 06, 2012
    I'll try your solution tomorrow morning. I've lost one day on this problem.. Thanks