1

We have a list deployed via a sandboxed WSP in SP 2010. The list is using list fields, not content types, so they are only defined in the Schema.xml and Elements.xml for the list instance.

When the WSP was originally deployed in production there was a bug in one of the lookup field's FieldXML and the ShowField attribute was missing.For some reason this didn't stop the lookup field from being created nor working as expected (hence why the bug wasn't caught during testing). However, a few months later a CU was installed on the farm and suddenly there was a new field on the list with the same display name but a different internal name (same as the original but with c000_ prepended) and the old field's lookup reference was broken.

This is when we found the issue with the ShowField attribute missing so we fixed the Schema.xml, deployed a new WSP with an UpgradeAction to apply the Schema.xml, and then deleted/created/copied all the data from the new field to a newly created field with the same ID. Everything was fine and we have gone through several upgrade deployments of our WSP since then without issue. However, another CU was installed and again the column was copied and the old one broken.

This is the new field's definition as output by PowerShell:

<Field 
DisplayName="My Field Display Name" 
Type="Lookup" 
Required="TRUE" 
List="{MyListGuid}" 
ID="{MyFieldGuid}" 
SourceID="{MySourceGuid}" 
StaticName="MyFieldName" 
Name="c000_MyFieldName" 
ColName="int5" 
RowOrdinal="0" 
ShowField="Title" 
RelationshipDeleteBehavior="None" 
Version="1" 
PreviousName="MyFieldName" 
/>

The PreviousName attribute tells me that the copied/clone field is obviously and intentionally being created by some process, presumably by the PSCONFIG upgrade process since we do not see the behavior during upgrades of our WSP (some of which have added fields to this particular list).

Comparing the field's XML to other lookup fields that are working perfectly fine the only thing that is different is the ShowField attribute that we had already fixed before the second CU was applied. This makes me think that somewhere in the SharePoint system, presumably in the database, is a copy of the original Schema.xml with the bug in it, and every time a CU is applied PSCONFIG references that Schema.xml, hits the bug, blows chunks, and then clones the field with the c000_ internal name.

Has anyone seen this behavior or have any knowledge of if/where SP stores the original Schema.xml that was used to provision a list instance?

Your Answer

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

Browse other questions tagged or ask your own question.