Lessons In TFS Work Item Customisation - System.State Is Special

I was customising some TFS 2008 Work Items, and I wanted to automate it so that the System.State value changes to a new state value when a custom field is changed to a specific value.

Quite simply, you can’t do this. The System.State field cannot have a value copied into it, or have other actions done to it.

If you are serious about automating like this, the only workaround is to create a custom program that listens for a particular event or custom action, and then use the rich TFS API and programmatically change the value of System.State.

The same applies to System.Reason.

Lessons in TFS Build - BuildShadowTask Failed

Recently I have been testing out the private accessor mechanism in .NET to test private methods. I know there is a large debate over whether private methods should be tested directly or whether they should only be tested via public methods. But, this post is not about whether to test private methods or not.

In this particular application, there are a large number of Visual Studio projects, so File References are used everywhere instead of Project References so that the solution file is as small as possible, containing only the projects that are under development.

I recently modified the TFS build definition to run the tests as part of the TFS build, and then the build failed with the following log information.

Using “BuildShadowTask” task from assembly “C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamTest\Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll”.

Task “BuildShadowTask”

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamTest\Microsoft.TeamTest.targets(18,5): error : Could not load file or assembly ‘[A.File.Referenced.Assembly.Name.Here], Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.

Done executing task “BuildShadowTask” – FAILED.

Done building target “ResolveTestReferences” in project “[My.Test.Project.Name.Here.csproj]” – FAILED.

When using the accessor mechanism to test private methods in a .NET language, the TFS build target ResolveTestReferences is called as part of the TFS Build process to build the xyz_Accessor.dll. [This build target resides in C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamTest\Microsoft.TeamTest.Targets.]

It appears that in order for this build target to be successful, the test project must contain:

  • At least one Project Reference (as opposed to a File Reference); and
  • Copy Local set to True on the reference to the assembly for which the Accessor will be created.

In order to work around the first problem, I created a blank Visual Studio project that I called “AccessorFix” which I include in my test solution. I then added a Project Reference from each test project that uses accessors to the AccessorFix project.

Now the TFS build of the shadow accessors completes successfully! Go figure.

TFS  Build