Most of the time you would always find some or the other issues while deploying your solution components from dev environment to any other environment like authoring or staging.
A couple of days before, we encountered one such issue while creating page instances using our custom content types on authoring environment. The error we encountered was
A duplicate name “YOUR CONTENT TYPE NAME” was found. at Microsoft.SharePoint.Publishing.Internal.Codebehind.CreatePagePage.HandleUnexpectedException(PublishingPage newPage, Exception exception)….
Also this error also wouldn’t even let the content deployment job to succeed.
After scratching my head for a couple of hours I finally found the issue/resolution and thought to share the same with the community.
The issue circles around the Content Type Association feature which we leveraged to binds our custom content type instance with the MOSS Pages library.
Background:
The content types we created for sprint 1 inherited from MOSS Page content type and accordingly they we associated them with the designated page layouts, packaged and deployed on authoring environment.
Everything worked fine here!!
Later in Sprint 2, due to some change in the customer requirement we had to update our custom content types to inherit from a different content type – ABC content type (provided by the customer). So accordingly we updated the IDs for all the content type but rest of the properties (like Name) remained same. This update was again packaged and redeployed on authoring environment.
The above error occurred!!
Root Cause:
Now once you redeployed a branding WSP, it would first delete the existing site content types and columns and other stuff but!! it won’t update the content type associations which are already there with the Pages library (at least for the content types having the same names). So our content types instances (apparently stale) in Pages library continued to inherit from Page content type instead of ABC content type. And here we ended up with two versions of content types with duplicate names.
Solution:
Just delete the stale content type instance from the Pages library before you redeploy the new package and everything should work fine. Simple isn’t it J
