Why Is My Content Type Replaced With a List Instance Detail When I Deploy My Project in Visual Studio, but Not When I Deploy it Manually?

Question

I'm doing something that I think is pretty typical. I've created a content type, descended from Document, to go into a document library, like so:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- Parent ContentType: Document (0x0101) -->
  <ContentType ID="0x010100abd74e6994114664b1ca6a8a710ff8cb"
               Name="Project Document"
               Group="WMC Project Management"
               Description="Document related to a project in the PMO portfolio."
               Inherits="TRUE"
               Version="0">
    <FieldRefs>
      <FieldRef ID="{B61A9DBA-5714-4E44-98AE-D410F84874BB}" Name="PortfolioProjectName" DisplayName="Portfolio Project Name" />
      <FieldRef ID="{811A8F99-3336-41AF-A1B1-C9DC624085C2}" Name="PortfolioProjectUrl" DisplayName="Portfolio Project URL" />
      <FieldRef ID="{938CF8E5-CCB2-49B1-91A6-595EB741F532}" Name="PortfolioProjectListItemId" DisplayName="Portfolio Project List Item ID" />
      <FieldRef ID="{9BE2CEAE-351D-4BC1-881B-44C7091FD501}" Name="ProjectDocumentType" DisplayName="Project Document Type" />
    </FieldRefs>
  </ContentType>
</Elements>

And I've created a document library to hold documents of this content type, like so:

<?xml version="1.0" encoding="utf-8"?>
<List xmlns:ows="Microsoft SharePoint" Title="Project Documents" Direction="$Resources:Direction;" FolderCreation="TRUE" EnableContentTypes="TRUE" Url="PMOProjectDocuments-ProjectDocumentLibrary" BaseType="1" xmlns="http://schemas.microsoft.com/sharepoint/">
  <MetaData>
    <ContentTypes>
      <ContentTypeRef ID="0x010100abd74e6994114664b1ca6a8a710ff8cb" />
    </ContentTypes>
    <Fields>
      (default document library fields elided for brevity)

      <Field ID="{B61A9DBA-5714-4E44-98AE-D410F84874BB}" Name="PortfolioProjectName" DisplayName="Portfolio Project Name" Type="Text" Group="WMC Project Management" ShowInNewForm="FALSE" ShowInEditForm="FALSE" />
      <Field ID="{811A8F99-3336-41AF-A1B1-C9DC624085C2}" Name="PortfolioProjectUrl" DisplayName="Portfolio Project URL" Type="URL" Group="WMC Project Management" ShowInNewForm="FALSE" ShowInEditForm="FALSE" />
      <Field ID="{938CF8E5-CCB2-49B1-91A6-595EB741F532}" Name="PortfolioProjectListItemId" DisplayName="Portfolio Project List Item ID" Type="Text" Indexed="TRUE" Group="WMC Project Management" ShowInNewForm="FALSE" ShowInEditForm="FALSE" />
      <Field ID="{9BE2CEAE-351D-4BC1-881B-44C7091FD501}" Name="ProjectDocumentType" Required="TRUE" DisplayName="Project Document Type" Type="Choice" Group="WMC Project Management">
        <CHOICES>
          <CHOICE>Charter</CHOICE>
          <CHOICE>Closure</CHOICE>
          <CHOICE>Lessons Learned</CHOICE>
          <CHOICE>Meetings</CHOICE>
          <CHOICE>Operational Assessment</CHOICE>
          <CHOICE>Project Deliverables</CHOICE>
          <CHOICE>Project Management Plan</CHOICE>
          <CHOICE>Project Tracking</CHOICE>
          <CHOICE>Requirements</CHOICE>
          <CHOICE>Status Report</CHOICE>
          <CHOICE>User Acceptance</CHOICE>
          <CHOICE>Vendor</CHOICE>
        </CHOICES>
      </Field>

    </Fields>
  (views and forms elided for brevity)
  </MetaData>
</List>

So why do I see the following when I hit my F5 key?

The list configuration shows a content type that's the same name as my list instance. That seems strange, so click on the "content type" name and I see that the "content type" really is my list instance, with the same description and everything. So I went to my test server, where I'd deployed a slightly different earlier version. The document library and content type appeared normal. Could there possibly be some difference in the way I deployed the project? I deployed the .wsp manually on the dev box... the very same .wsp I'd just debugged with F5.

When I do so, my document library and content type look perfectly normal, and so does the content type itself.

(A similar (but snarkier) writeup with screenshots appears on my blog at http://www.jasonspecland.com/2012/02/06/hey-sharepoint-why-do-you-screw-up-my-content-type-when-i-deploy-it-through-visual-studio/ )

So... Why doesn't my document library get the right content type when I deploy it in Visual Studio, but does when I deploy it manually?

Answer 1

Oh, the content-type minefield, how I love thee...

Quirks

• When a list is provisioned it makes a copy of the schemas of each content type. These copies are no longer dynamically connected to the source content type. As a result, when the underlying content type changes, all lists currently provisioned do not change.

• If you delete a content type yet there are lists provisioned with it, all fields that were in the content type will remain in the list. They will simply no longer be associated to the content type. (This is Microsoft's way of preventing you from losing data)

• If you then reprovision the content type under the same ID, it may magically once again be listed when you view the list definition. However, it will still retain the old schema.
• If you are looking at a list in the UI then click on the name of the content type, it does NOT take you to the content type definition. It takes you to the copy of the content type that is attached to the list. In that list there will be another link to the parent type and that will take you to the actual content type. This can be confusing.
• Specifically updating a content type and telling it to cascade changes doesn't actually do anything useful. For example, new fields are not added to existing lists using the content type, nor are deleted fields removed from these lists. It doesn't appear to actually do anything other than take longer.
• etc..

Possible causes

• the list is already provisioned at the time that the feature is deployed, in which case it retains the original schema of the content type
• Visual Studio does a retract before deploying and by default retract does not unprovision (?) list instances created in the feature. Most deployments have a custom feature receiver that does that on deactivate. If your app does not have that you may be butting heads with the previous issue.
• You may want to get in the habit of deleting any lists provisioned with the content type prior to deploying it.

The short way to sum up all of the above is to get your content types as close to right as you possibly can on the first iteration because changing them once they go live will be something that will teach you all sorts of new curse words.