Losing Site Column Information on Redeploy

Mike BerrymanI ran into a nasty little bug a little while ago concerning Site Columns added through a sharepoint feature.  First, a little background:

I have a sharepoint project that defines a site template, the end result being the user can use this site template to create a subsite that comes preloaded with certain data.  Part of this template defines a set of site columns for some custom content types to use.  Of these site columns, I had a lookup field defined as follows in the elements.xml for the module:

 <Field Type="LookupMulti" Mult="TRUE"
        Sortable="FALSE" RelationshipDeleteBehavior="None"
        DisplayName="Dependant Groups" Required="FALSE"
        EnforceUniqueValues="FALSE" List="Lists/Groups"
        WebId="" ShowField="Title"
        UnlimitedLengthInDocumentLibrary="FALSE"
        Group="Subsite Site Columns" ID="{someguid}"
        SourceID="http://schemas.microsoft.com/sharepoint/v3"
        StaticName="DependantGroups" Name="DependantGroups"/>

The field created is a multiple value lookup field to the Groups list, which is also defined and instantiated in the same site template (Notice the List=”Lists/Groups” portion of the definition – normally this attribute takes a GUID to another list, but since the list doesn’t exist and we have no way of knowing the GUID before it’s created, this allows us to use a path to the list instead).  When I would deploy this site template and create a subsite using the template, everything would work just fine. However, the next time I would deploy the site template, regardless of whether or not I made a change to this site column definition, the column in all sites based off of this site template would break, losing its lookup information to the ‘Groups’ list, and thus be unusable.

This was driving me nuts.  I spent quite a while trying to track down why it would work whenever I created a new site, but then would immediately break after my next redeploy.  I changed all sorts of properties on the field, manually created a field similar to it and then examined the definition of that field, and even got to the point where I just had the lookup field look to its own list with no luck whatsoever.  Eventually I tried something that provided the “Ah-ha!” moment: I started to deploy my subsequent updates using powershell instead of visual studio.

Voila! Suddenly everything started working just fine, and I could rule out insanity on my part (well, at least in this case).  Knowing visual studio now had something to do with my woes, I was able to quickly find a microsoft KB article semi-related to this subject: http://support.microsoft.com/kb/2022443.  While that article specifically refers to changes in GUIDs causing the problem, any changes to any critical properties of a field would cause the same baffling behavior.  Somehow, for some reason, visual studio “caches” field definitions (possibly other things, too) when you deploy a sharepoint project the first time after opening up visual studio.  So, in my case, the very first time I had deployed my site column definition for this new site column, I must have had a critical property incorrect.  After fixing it and redeploying, the site column definition would update in the template (explaining why creating a new site from the template would work just fine), but the “cached” version of the site column would get pushed out to all the already-existing site column definitions.

Baffling, I know, but the simple solution, and the one recommended in that KB article, is to just shut down visual studio and re-open it.  This clears whatever information visual studio is holding onto, and your site column definitions will work just fine.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s