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

   Submit to Reddit      
  

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 MSBuild - Targets Are Called Only Once

   Submit to Reddit      
  

By design, targets in a MSBuild process are only called once. This is an important concept to understand, as it is unusual for the typical developer.

I had a situation where I wanted to call the same target from a few places in my MSBuild project - but I wanted to pass in different property values. I didn't want to repeat myself (DRY principle).

If <CallTarget ...> is used then the target is only called once within that process.

I found a sneaky way to work around this by examining the file C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\ Microsoft.TeamFoundation.Build.targets

Instead of using <CallTarget ...>, use <MSBuild ...> which spawns off a new MSBuild process, thus allowing the target to be called each time.

<MSBuild Projects="$(MSBuildProjectFile)" Targets="MyTarget" Properties="MyProperty1=blah;MyProperty2=$(MyVariable)\blah2" />

Lessons in MSBuild - Applying the Single Responsibility Principle

   Submit to Reddit      
  

As an experienced developer, I promote the use of good practices in object-oriented designs.

I was modifying a number of MSBuild and TFS Build project files for several related environments and I noticed that they both duplicated information and each had more than one responsibility - such as specifying the solution to build and compilation settings such as code analysis, configuring testing, and then perhaps performing some custom operations.

I wondered if I could apply the Single Responsibility Principle to the build project files.

Indeed, you can split your project files into multiple files, and from the main project you can import the other file by using the following syntax.

<Import Project="MyCommonTargets.proj" />

Lessons in TFS Build - BuildShadowTask Failed

   Submit to Reddit      
  

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.