Multiple Inherited Custom InfoPath Content Types Deployed Through a Solution Feature

HaloX — Tue, 16 Mar 2010 22:41:54 GMT

My stuggle is this:

I have created a library of content types based on my clients existing taxonomy. There exists a level of inheritance starting with item (0x01) that I inherited and finally moving up to documents. This was to enforce custom policies and expiration with regards to records management. Now, for documents everything is hunky dory. My problem begins when I move a an XML content type. I would like for a core form to have the inheritable fields that my custom Document content types leverages for a consistent taxonomy. I want to expire XML forms like any other forms.

Lots of people out there blog about how to publish InfoPath forms as content types, but NONE NONE have done it thorugh features. Now I have used a feature and the problem begins with the feature receiver. Micosoft does some friken magic with the Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver. I know that it sets the DocumentTemplate property, but it creates the content type and wires the content type to the InfoPath form. That is, that it discovers the promoted fields and it shoves the promoted fields and stuff into the content types SchemaXml.

OK so below is my feature file.

<?xml version="1.0" encoding="utf-8"?>

<Feature xmlns="http://schemas.microsoft.com/sharepoint/"

Id="{E114B463-A6F6-40af-9662-8FADACCBCFBE}"

Title="Some Core File"

Description="content"

Version="12.0.0.0"

Hidden="TRUE"

Scope="Site"

DefaultResourceFile="ipfscore"

ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver"

ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" ><ActivationDependencies>

</ActivationDependencies>

</ElementManifests>

</Feature>

Now next is my manifest file:

<?xml version="1.0" encoding="utf-8" ?>

<ContentType ID="0x010101002452e99B7A9F4693700A0B035F35F4D000Fae28A9111A0E17ADF213B143FD639A2"

Name="Some form"

Version="0"

Sealed="FALSE"

Group="My Corp Content Types"

Description="some form that inherits from another."><FieldRefs>

</FieldRefs>

</ContentType>

</Elements>

Now the way it breaks down is this. I want this form content type to inherit from a base form content type. Here is the id breakdown:

0x010101 - Form Content Type

00 - Breaks up id's

2452e99B7A9F4693700A0B035F35F4D0 - Other parent ID

00 - Breaks up id's

Fae28A9111A0E17ADF213B143FD639A2 - Custom ID for this content type.

Now I did also try instead of using the 0x01010100[Parent GUID]00[New Guid] to 0x01010100[Parent GUID]01, but it still didn't work.

The net result is that the content type that is created doesn't point to my infopath form AND worst of all if I try and open my infopath form in browser from the FormServerTemplates library, it doesnt work. Now with this feature deployed if I publish a different form through InfoPath where the group will then appear, Microsoft Office InfoPath, that another instance of my content type will appear under this grouping with a number 1 appended like so: SomeCoreFile1.

I am aware of the inheritance issues with xml content types, that is the issue when when a field is added to the parent that it doesn't update the inherited child types. I can deal with that. I just want to see a real work example, if it is even possible, where a InfoPath Browser Enabled form is deployed through a soultion feature binding it to another custom InfoPath content type.

Browser Forms

Multiple Inherited Custom InfoPath Content Types Deployed Through a Solution Feature