In TFS 2015, we deprecated the ability to change the syncnamechanges property on a field. Therefore, you can no longer create projects that use the OOB templates in new collections for which the following conditions are true:
You uploaded a custom process to a new collection that has a field that shares the same reference name as an OOB template field.
The syncnamechanges property is false for that field.
You created a project by using the custom process template.
In Update 1, we will restore the ability to change the syncnamechanges property. In the meantime, you can try one of these workarounds:
Update the custom process template to match the syncnamechanges property of the OOB template, and upload it to a new collection.
Contact Customer Support to have them to provide a script to fix the conflicting fields.
Fields marked as "syncnamechanges=false" through identity rules cause issues for the client object model
In TFS 2015, we introduced the concept of an identity field. A field is considered to be an identity field if it has any rules on it that relate to identities, such as <ValidUser />. This enables us to fix issues that involve duplicate display names. Previously, if two users had the same name, you could not differentiate between them. Now that we have identity fields, we store the DisplayPart as "display name <email or domain\alias>." For example, instead of "Sean Contoso," the DisplayPart is now stored as "Sean Contoso <firstname.lastname@example.org>."
If syncnamechanges=true is set for a field, we store the Constant ID of the value instead of the actual string value for the field. If syncnamechanges=false is set, the string value is directly stored on the work item. For identity fields, there is an issue that affects the client object model. Because the string value is stored, we are returning that string value as-is to the client. This causes the client-side rule engine to treat the field as invalid because it is not expecting the value in the format of "Sean Contoso <email@example.com>."
Before you upgrade, update any templates that have the syncnamechangesproperty set to false for fields that have identity rules to set the syncnamechanges property to true. You must do this before you upgrade because the ability to change the state of the syncnamechanges property is removed from Team Foundation Server 2015.
Add an <AllowExistingValue /> rule on any identity field that has the syncnamechanges property set to false. This enables the client object model rule engine to accept the existing value. This unblocks customers until we can provide a script that can convert fields that have their syncnamechanges property set to false to fields that have their syncnamechanges property set to true.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.