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.