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.

1<Import Project="MyCommonTargets.proj" />

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.

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

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.

The Microsoft build engine (MSBuild) is not necessarily the easiest to learn, and documentation and examples can be difficult to find.

There is however an excellent book written by Sayed Ibrahim Hashimi and William Bartholomew titled “Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build” (Microsoft Press, 2009, ISBN-13: 978-0-7356-2628-7). I very strongly recommend purchasing this book if you are serious about learning MSBuild.

In this series of lessons I will be discussing a few MSBuild related tips that I found useful to understand during my recent dabbling in MSBuild 3.5 projects.