3

I can't find a CAML based solution to the following problem, I appreciate that if I created/edited the content type using the object model it would probably be OK but for this situation I need to use CAML.

I have the following content type hierachy, in reality it is more complicated with more types but the below serves to demonstrate.

BaseContentType : Item
    DerivedContentType : BaseContentType
        MoreDerivedContentType : DerivedContentType

In the elements.xml file where I define the content types I have the following (simplified) definition for BaseContentType:

<ContentType ID="0x010088168591bb094583a2d63c13d73293a5"
    Name="[Name]"
    Group="[Group]"        
    Description="[Description]"
    FeatureId="86b34829-09ab-4591-9646-55898bb4241d"
    Inherits="TRUE">
    <FieldRefs>
    <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" Required="FALSE" ShowInDisplayForm="FALSE" ShowInEditForm="FALSE" ShowInNewForm="FALSE" Sealed="TRUE" />
    <FieldRef ID="{7612E6EF-BEC7-480A-9820-2F7EDD1D945F}" Name="AnotherField" DisplayName="AnotherField" Required="FALSE" />
    </FieldRefs>
</ContentType>

As you can see I am trying to change the visibility and required status of the built-in title field, I could equally be using RemoveFieldRef, the behaviour is the same. With the above definition my feature activates OK but the changes to the Title field are not made. It is visible and required in all content types. This seems to be well documented online, here for example - http://msmvps.com/blogs/windsor/archive/2011/05/02/custom-content-types-and-inherits-in-sharepoint-2010.aspx - it is discussed very clearly. The generally accepted solution is to set Inherits="FALSE" and then SharePoint honours the changes to the inherited fields.

However when I set inherits to false I get the following error:

The parent content type specified by content type identifier 0x010088168591BB094583A2D63C13D73293A5 does not exist

There seems to be a combination of undocumented and unexpected behaviour here. Inherits doesn't work as defined in the docs and has some unexpected side effects. One of these is that multiple inherited content types seem to be impossible without inherits set to true.

Can anyone provide a clearer understanding of this and possibly a declarative solution?

Improve this question
2
  • I have to some extent solved my problem although it isn't a true answer to my question as my current solution is not CAML based. The first step was to delete the Title field from the ContentTypes programmatically in a feature receiver. However now SharePoint handily recreates the Title field on the ListInstance, presumably as it is defined in the default ONET file. I then created a ListAdded event receiver, which deletes the Title field from the List and all ContentTypes within if the TemplateId matches.
    – robwilliams
    Commented Jan 19, 2012 at 15:52
  • @PirateEric - I will happily defer to your better judgement as this is indeed my first question here in comparison to your quite epic rep. However, the tag 2010 was quite deliberate. To the best of my knowledge the issue surrounding the behaviour of Inherits attribute for ContentTypes is specific to 2010 and this problem would not have exhibited in the same manner in 2007..?
    – robwilliams
    Commented Jan 19, 2012 at 15:54

2 Answers 2

Reset to default
1

You were right in your original post about the Content Type Id - I misread as it being a derived content type instead of the base content type. I've deleted my other answer.

I found I was able to recreate your issue when my parent content type had inherits set to false and my child content type had inherits set to true. I was lead this direction because the error seemed to imply that the child content type couldn't find a parent content type to inherit from. By changing the child inherits property to false my solution deployed successfully.

I am not familiar with the nature of the inherits attribute as I haven't really done any content type definitions in 2010 but it would seem that you will have the best experience by letting the content type ids define the inheritance and updating field refs as needed. To me this doesn't seem like the expected behavior but this is how we did things in 2007.

Perhaps Microsoft didn't get around to fully implementing the functionality desired to improve this development process in 2010 and as such we have a property that causes more problems than it solves.

Improve this answer
1
  • I think you're right there. In reality it is even stranger than this. The behaviour is in fact different for three different configurations; TRUE, FALSE and not defined. That is if you don't set the attribute at all the behaviour, with respect to these subtleties at least, is slightly different again. I have resolved to using a Feature Receiver to fix up the fields on activation; we have to do this for Lookups which can't find their list anyway so... thanks for the research, if I get time I might try another run with the configuration you mentioned. Thanks for the extra research!
    – robwilliams
    Commented Jan 24, 2012 at 17:53
0

I had the same "parent content type ... does not exist" error with nested content types:

  1. Document
  2. My Base CT
  3. My Derived CT

I moved My Base CT into its own feature and ordered the package so the base CT feature was activated before the derived CT feature. This seems to have solved the issue. The project is still in dev so not yet proved in prod.

Btw, I had a farm solution because I couldn't get the field inheritance to work in the sandbox solution.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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