Doodle Graphics

Just when you thought it was safe to enter source control

Apparently, we weren't finished with the upgrade to Team Foundation Server 2005. We've upgraded, apparently people are successfully (after a couple of false starts*) checking stuff out, working on it, and checking it back in, so it's all good… Or is it?

The full series

• Part 1: In which the scene is set.
• Part 2: In which the Hands on Labs are completed.
• Part 3: Where we attempt the migration.
• Part 4: In which conclusions are drawn.
• Part 5: In which errors are noted (this post).

Part 5: In Which Errors Are Noted

You may recall that in Part 3 I had to fiddle around with a few report definitions and import a new work item into the process template. What I forgot to note down in the blog was the fact that I also had to tweak the names of a couple of fields in one of the work items to successfully import - I probably forgot to write about it because it's something I often had to do when mucking around with them.

My long suffering Network Manager pointed out to me that the Application Log on the TFS server Newyork was being filled with the following error:

TF53010: The following error has occurred in a Team Foundation component or extension:
Date (UTC): 03/05/2011 17:57:56
Machine: NEWYORK
Application Domain: TfsJobAgent.exe
Assembly: Microsoft.TeamFoundation.Framework.Server, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; v2.0.50727
Service Host:
Process Details:
  Process Name: TFSJobAgent
  Process Id: 4008
  Thread Id: 1524

Detailed Message:
  Adapter: Microsoft.TeamFoundation.WorkItemTracking.WorkItemTrackingWarehouseAdapter
  Team Project Collection: Legacy

TF221161: There are conflicting definitions of the following work item fields in the warehouse: System.ExternalLinkCount<->System.ExternalLinkCount (DefaultCollection); System.HyperLinkCount<->System.HyperLinkCount (DefaultCollection); System.AttachedFileCount<->System.AttachedFileCount (DefaultCollection). These conflicting definitions come from different project collections. Work items from project collection Legacy will not be updated until the conflict is resolved. You can resolve the conflict by making the definitions of the field the same in all project collections, or marking the field as non-reportable in the project collection Legacy. For more information, see the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=160807).

The link at the end of the error gives you pretty much all the information you need to resolve the issue, but it bears repeating so that I don't forget it again:

Start by doing a quick compare and contrast of the two systems using the Visual Studio 2010 command prompt and the Work Item Template Admin tool (witadmin):

First, call ListFields on both collections to compare their settings:

witadmin listfields /collection:http://newyork:8080/tfs/Legacy /n:System.ExternalLinkCount

This resulted in:

Field: System.ExternalLinkCount

Name: ExternalLinkCount

Type: Integer

Use: System

Field Indexed: False

Reportable As: measure:sum

Calling ListFields with the original collection name resulted in:

Field: System.ExternalLinkCount

Name: External Link Count

Type: Integer

Use: System Field

Indexed: False

Reportable As: measure:sum

Note the spaces in the Name field - this is what's causing the problem - the fields both have the same reference names, but different display names, these need to be in synch to stop the errors.

Seeing as the fields where currently being reported on in the original project collection, it makes sense to use the version with spaces:

witadmin changefield /collection:http://newyork:8080/tfs/Legacy /n:System.ExternalLinkCount /name:"External Link Count"

Note the quotes around the new name value. Finally validate that the field was correctly updated by re-issuing the ListFields command - I won't encourage you to add the optional /noprompt parameter, but it's there if you don't want to confirm each step.

Repeat this for each field listed in the error, and you should now be good to go.

* The false starts were those expected: The developers were still working with VS 2008, and so were getting a permissions issue when trying to connect to TFS 2010. This is resolved by:

1. Installing the relevant Forward Compatibility Update (2005 and 2008)
2. When connecting to the server, rather than entering just the server name in the "Name" field, supplying the entire path to the project collection:
   http://newyork:8080/tfs/Legacy

Filed under: TFS