MSBuild Conditions on Targets

This post is related to my  previous post MSBuild RE: Enforcing the Build Agent in a Team Build which is a response on the post by Michael Ruminer at http://manicprogrammer.com/cs/blogs/michaelruminer/archive/2008/06/19/enforcing-the-build-agent-in-a-team-build.aspx.

Basically every MSBuild element can contain a Condtions attribute. You can read more at MSBuild Conditions. So even targets can have conditions attached to them! Despite the fact that you can do this, you should not. I recommend that you do not use conditions on targets. Conditions on targets seem straight forward but after you take a closer look they are more complicated. We can take a look at some of the items that come to mind here.

Conditions on targets and DependsOnTargets don’t play well

Take a look at this simple project file

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="2.0"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
         DefaultTargets="Demo">

  <PropertyGroup>
    <AllowTarget>true</AllowTarget>
  </PropertyGroup>

  <Target Name="SupressTarget">
    <CreateProperty Value="false">
      <Output PropertyName="AllowTarget" TaskParameter="Value"/>
    </CreateProperty>
    <Message Text=" ==== SupressTarget ==== " Importance="high"/>
    <Message Text="AllowTarget: $(AllowTarget)"/>
  </Target>
 
 
  <Target Name="Demo" Condition="'$(AllowTarget)'=='true'"
          DependsOnTargets="SupressTarget">
    <Message Text=" ===== Demo ===== " Importance="high" />

    <Message Text="AllowTarget: $(AllowTarget)"/>
  </Target>
 
</Project>

In this project the main target is Demo and it depends on a target SupressTarget which actually disables the Demo target based on its condition. If you execute the command msbuild /t:Demo you get the results shown below.

Most users would expect that the target SupressTarget target would execute which sets the AllowTarget value to false, and then the Demo target is skipped. But what is happening here is that by the time DependsOnTargets is evaluated the condition has already been evaluated and has passed! The even more interesting thing here is if you execute msbuild /t:SupressTarget;Demo the results are shown below.

 

So this time it was skipped, because SupressTarget was called before the Demo target was invoked so the condition evaluated to false.

 

Conditions and target batching doesn’t work well either

If you are batching a target and you want to execute the target for some batches but not others, this cannot be achieved with target conditions, for a few reasons but the simplest is: Either a target is or is not defined. When the target is going to be executed for the first time the condition is evaluated. If the condition is true it will exist, otherwise it will not.

I thought of some other issues but they are not coming to me at this time, but I think this is enough to deter you from using target dependencies. Instead of target dependencies you should take a look at other way of achieving the same results.

 

Sayed Ibrahim Hashimi

Team Build + MSBuild Properties

If you are using Team Foundation Server as your SCM tool, I hope you're taking advantage of using the Team Build tool to create re-producable public builds for your projects. Very cool, and very useful, especially for those Enterprise applications. As you use Team Build you'll need to make changes to how your build process is executed. You can make the customizations in the TFSBuild.proj file. This is the file that will drive your team build. In this file there are many properties declared that are generated by the New Build Type Creation Wizard. These properties are contained in the first PropertyGroup element in that file. Some of these properties include; Description, DropLocation,BuildDirectoryPath,... which are used internally by Team Build to setup the build. Of course Team Build uses MSBuild to actually execute the build, but some things need to happen before/after MSBuild gets involved. For instance creating the Build report, which require those values. In the ideal world you'd expect for those values to be gathered using the MSBuild Object Model, but this is not the case. Team Build is extracting those values as they are declared.
There has been a few posts about this particular problem on the MSBuild MSDN Forum. Those posts are at:

Post: Property Evaluation Order (beta 3)
Properties in properties

In the post Property Evaluation Order (beta 3) I provide a workaround for most situations, but its not always perfect. Here it is for you to see:

It seems like Team build is not using the msbuild object model to get those evaluated properties, but instead are simply extracting the text value from those property declarations.

I tried to overwirte it in different places in the project file as well, with no luck. It always took the first declaration. I'm guessing that the property is not able to be overwritten because it is passed in as a command line parameter to msbuild.exe by team build. But there is a workaround that solves some of the issues. In your TFSBuild.proj file, modify the DropLocation to one that doesn't use any properties and insert the following towards the bottom:

  <PropertyGroup>

    <RootProjectFolder>ProjectX</RootProjectFolder>

 

    <DropBuildDependsOn>

      FixDropLocation;

      $(DropBuildDependsOn);

    </DropBuildDependsOn>

  </PropertyGroup>

 

  <Target Name="FixDropLocation">

    <CreateProperty Value="$(DropLocation)\$(RootProjectFolder)">

      <Output TaskParameter="Value" PropertyName="DropLocation"/>

    </CreateProperty>

    <Message Text="Drop loc: $(DropLocation)" Importance="high"/>

  </Target>

This prepends the FixDropLocation to the DropBuildDependsOn list of targets, so it will be executed before the DropBuild target. This cause your project drop files to be dropped in the location tat you want. This is able to overwrite the DropLocation property becuase we are using the CreateProperty task to overwrite this instead of the normal property declaration.

This is not however a perfect solution, because your build log will always be located in the DropLocation that was originally declared (the one w/o the property embedded within it). And in the Team build type history the drop location will also have this location as well. But it does place the files where you want them :)

Unfortunately it looks like the DropLocation that is given to TFS is happening outside the scope of MSBuild so I'm not sure you have a lot of options. You can't even pass this as a command line parameter to the tfsbuild.exe utility either. Let me know if this  is not clear.

Sayed Ibrahim Hashimi

TFS Build Error

Lately I've been using Team Foundation Server (TFS) for my source control and Team Build to perfom builds on a dedicated machine. Everything was working pretty good until the other night, I created a new team project and added some projects to the source control. Following this I created a new Team Build and tried to execute it, but I received an error, TF42053: The build machine is not configured to build for server..." I received this error when I tried to invoke Team Builds that were previously building correctly as well, not just on the new project. The image of the dialog box is shown below (click for larget image).

As instructed I opened up the TFSBuildService.exe config file which is at %Program Files%/Microsoft Visual Studio 8/Common7/IDE/PrivateAssemblies/TFSBuildService.exe.config, I opened up that file and located the AllowedTeamServer key element. Originally it looked like:

<add key="AllowedTeamServer" value="" />

By the way my TFS setup is on a single tier, so the application and data tier are both on the same machine, and that is also the machine that I was trying to run the build on. So I changed the value to:

<add key="AllowedTeamServer" value="MACHINE_NAME"/>

Then I restarted the service and invoked the team build again, and all was fine. I'm not sure why I was able to build previously but not now. The only things I can think of a few changes to the envrionment:
  1) a minor hardware change (I disconnected a removable hard drive from that machine)
  2) the IP address of that machine changed
  3) machine was restarted a few times
  4) new team project with its source control
So I'm not quite sure why I received this error, but I'm glad it was an easy fix. Now I can continue working on my project.

Sayed Ibrahim Hashimi