Names changed for core WIT fields, and implications thereof

In work item tracking, there are several system fields that always exist in every work item type. These fields have both a reference name and a friendly name.

The friendly name for some core fields have changed. They are:

Reference Name	Old Friendly Name	New Friendly Name	What release the change was introduced
System.AreaID	AreaID	Area ID	RC
System.IterationID	IterationID	Iteration ID	RC
System.HyperLinkCount	HyperLinkCount	HyperLink Count	Beta2
System.ExternalLinkCount	ExternalLinkCount	External Link Count	Beta2
System.AttachedFileCount	AttachedFileCount	Attached File Count	Beta2

There should be no implications for these name changes. These friendly names have always been available to be modified by the customer (using witfields in 2005/2008 versions, and witadmin in 2010 versions). All parts of TFS refer to the reference name, which remains unchanged.

There are a few exceptions to this:

• If you have existing team projects in a team project collection, and those team projects referred to the fields by the old friendly name, then any new new projects created on that team project collection will adopt the existing friendly name. We have special logic in the project creation that ignores changes to friendly names, and just adopts the existing friendly name.
• While the project creation process has special logic to ignore changes to friendly names, witadmin does not. So uploading any work item types via witadmin will fail.
• If you ever mark any of the above fields as reportable (none are reportable by default), and, you have one project collection with the old friendly name, and another project collection with the new friendly name, then the last project collection to synch to the warehouse will have a field name collision No data for that project collection will be synched to the warehouse until you resolve the field name conflict. This can be done using witadmin.
• If you mark the above fields as reportable, have resolved the name conflicts, and have written reports that reference the friendly name, rather than the reference name, then those reports will not work until you have updated them to refer to the new friendly name.

NOTE: If you need to resolve the naming conflict, you can either rename the field in the work item type definition to match the server's or change the server's name using witadmin changefield /name.

If you do nothing, you will probably be just fine.

However, if you are nervous, than after installing the RC or later build, then use witadmin to rename the fields to the new name, and update any process templates you are using that reference the old name. The MSF Agile/CMMI process templates have been updated to reflect the new name for versions RC or later.

Comments

• Anonymous
  April 17, 2010
  Hi Gregg! It looks like several other fields changed between the early Beta 2 and RTM although I'm not sure when the changes were introduced.  They are mostly on the Bug and Test Case work item types: Reference Name System.Id Microsoft.VSTS.TCM.ReproSteps Microsoft.VSTS.TCM.AutomatedTestName Microsoft.VSTS.TCM.AutomatedTestStorage Microsoft.VSTS.TCM.AutomatedTestId Microsoft.VSTS.TCM.AutomatedTestType Microsoft.VSTS.TCM.LocalDataSource

• Anonymous
  July 07, 2010
  The comment has been removed