0

We have a strange situation where we have managed to get two copies of a custom content type referenced in a document library.

The content types had the same name and content type ID, and this ID was that of the content type in the gallery. Usually a content type referred to in a list will have a child ID of the one that is held in the gallery.

The original occurrence of this issue was successfully resolved by removing the last instance of each of these duplicates from each affected document library.

//where contentTypeId and contentTypeName are defined for a duplicate

var contentTypes = from ct in documentLibrary.ContentTypes.Caset<SPContentTypes>()
                   where ct.Id.Equals(contentTypeId) && ct.Name.Equals(contentTypeName)
                   select ct;

contentTypes.Last().Delete();

The problem has returned and this time two different content types have both been duplicated in affected document libraries.

When trying to reuse the previous approach to delete either of the "Content Type A" duplicates we get an error - "A duplicate content type "Content Type B" was found"

The opposite issue occurs when trying to delete "Content Type B", so it would seem that each duplicate is preventing the other from being fixed. It also stops any management of content types in these libraries.

Is it possible to batch up deletions of content types to skip around the validation? I was wondering SPWeb.ProcessBatchData() would be any use but it seems woefully underdocumented.

As an aside, the cause of this issue is in a third party piece of software - a fix is being pursued

Improve this question

1 Answer 1

Reset to default
1

It is really strange on how you actually managed to get the same ID and in the same list, did you managed to reproduce that (probably by deploying one via VS solution after copying the CT-Id from another..but still VS should complain)?

To make sure you deletion is for real successful you need to check the database tables as this situation could generate orphans. Have a look at this procedure (use it on your own risk - it did successfully helped me!) http://apichot.blogspot.ch/2009/11/how-to-delete-orphan-content-type.html

To get back to your question: - validation is always in place, because there is always the risk that the CT is in Use, therefore cannot not be deleted while referenced. You could always check SPContentTypeUsage.GetUsages Method (see more here http://www.apterasoftware.com/Blog/Post/10-05-12/Determine_Content_Type_Usage_In_Your_Site_Collection.aspx) before attempting deletion. Also, you should envision using the UPGRADE features (new in SP2010) to perform updates on Content Types because you won't be able to delete them and for sure you end up with orphans if you succeed by any chance using back-door methods!

Improve this answer
4
  • We've noticed that the behaviour of content types can be a bit odd when doing things declaratively (i.e. in XML content type definitions), especially when they are modified after being used - this is a good way of skipping some of the validation I think ;-)! (Inadvisable though!) I think the ID thing is probably a result of SharePoint getting a bit confused - after all, when we deleted one of the original problematic content types, the ID of the remaining one reverted to being a child ID of the one in the site collection gallery.
    – SHug
    Sep 4, 2012 at 15:14
  • If I may, using the SPContentTypeUsage is the recomanded way (SharePoint uses it as well) to validate (not skip) if CT is in use. Then, the ID of each CT is unique as it builds up upon its parent ID by attaching either a number 1,2,3 for versions, or entire GUID-like part for children. In your case, i would strongly suggest you try your deployment procedures on a new (fresh) Site Collection, as it looks to me that things are already messed up in the database. Also, declarativelly is actually also a best practice, particularly that VS allows export of fields via Server Explorer quite easy.
    – Marius Constantinescu - MVP
    Sep 5, 2012 at 7:32
  • Yeah, unfortunately this is occurring on existing content types on sites that have been around for ages. It's not a problem with the content type creation as it's not happening everywhere, just where this third party software has been running. I'm looking for a remedy to the symptom, as I can't cure the disease (as it's in the other software). ;-)
    – SHug
    Sep 5, 2012 at 9:20
  • As a last resort, try using tools such as the SharePoint manager to get a better glimpse of your CTs. Also, keep checking the content database for any records that could identify why. If possible, make your CT's children of those ones, and remove the "Inheritance" attribute, which would give you total freedom to add/remove properties while maintain a relation.
    – Marius Constantinescu - MVP
    Sep 5, 2012 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.