Successfully upgraded TFS 2010 from Beta 2 to RC on EC2

Once again I have my TFS instance on EC2 up to date, and I’m able to connect to it successfully from my Visual Studio 2010 RC instance here at home. One word of advice though; once you install VS2010 RC, VS seems to crash if you then try to install Team Explorer 2010 Beta 2 so make sure your code is all checked in before the upgrade, otherwise won’t be able to make this available to anyone else on your team until the process is complete!

I was surprised that I didn’t run into a few issues as part of this process, but the upgrade was fairly painless – thanks mostly to the TFS 2010 Beta 2 to RC Upgrade Guide posted by Brian Krieger. I ran into a bit of trouble setting up SSRS and WSS again … but that was my own fault, not an issue with the upgrade process (I’d forgotten the credentials I’d used last time … L).

The good news though is that now seems to be working, including my old VS2010 Beta 2 solution files which opened without any issues or the need for an upgrade. 

I did come across a breaking change in the TFS APIs. It would seem that the TeamFoundationServer class no longer supports the AuthorisedIdentity property (in fact the TeamFoundationServer class has now been depreciated in favor of TeamProjectCollection). Changing the reference to use TeamProjectCollection.AuthorizedIdentity seems to have resolved the problem, and everything is building again.

Custom States values for Work Items in TFS 2010

In one of my previous blog posts I was asked how to add custom ‘State’ values for a work item in Team Foundation Server 2010.

The state field is a unique field within the Work Item definition, and the mechanism to edit the values is not quite as intuitive as with other fields. Normally, the allowed values for a field are stored directly within the Field tag, using an AllowedValues (or even SuggestedValues) node:

<FIELD name=“Priority” refname=“Microsoft.VSTS.Common.Priority” type=“Integer” reportable=“dimension“>
  <HELPTEXT>Importance to business</HELPTEXT>
  <ALLOWEDVALUES expanditems=“true“>
    <LISTITEM value=“1“ />
    <LISTITEM value=“2“ />
    <LISTITEM value=“3“ />
    <LISTITEM value=“4“ />
  </ALLOWEDVALUES>
  <DEFAULT from=“value” value=“2“ />
</FIELD>

The State field is slightly different – the field definition itself doesn’t actually contain any of the valid state values:

<FIELD name=“State” refname=“System.State” type=“String” reportable=“dimension“>
  <HELPTEXT>Active = work remains to be done. Closed = tested and checked in.</HELPTEXT>
</FIELD>

Instead, value state values are added to the States node within the Workflow node of the Work Item. See the below for adding a ‘Proposed’ state to the Work Item:

<WORKFLOW>
  <STATES>
    <STATE value=”Proposed” />
    <STATE value=“Active“>
      <FIELDS>
        <FIELD refname=“Microsoft.VSTS.Common.ClosedDate“>
          <EMPTY />
        </FIELD>
        <FIELD refname=“Microsoft.VSTS.Common.ClosedBy“>
          <ALLOWEXISTINGVALUE />
          <EMPTY />
        </FIELD>
      </FIELDS>
    </STATE>
    <STATE value=“Closed“ />
  </STATES>
  …

Transition rules can then be applied to the Work Item State using the Transitions node:

<TRANSITIONS>
  <TRANSITION from=“” to=“Proposed“>
    <REASONS>
      <DEFAULTREASON value=“New“ />
    </REASONS>
  </TRANSITION>
  <TRANSITION from=“Proposed” to=“Active“>
  …

With these modifications made, you should now be able to re-import the Work Item Type definition file back into Team Foundation Server 2010.

C:\TFS>”C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\witadmin” importwitd /collection:localhost\defaultcollection /p:”{ExistingProjectName}” /f:Task.xml

Note – don’t forget to restart your Visual Studio environment before trying to use your updated Work Item in order to refresh the cache.