Changing Drop Location in team build
- Hi,
We have developers at two different sites. Is it possible to have a single team build type that we can run on build machines at each site using a drop location local to the site?
Dean
Answers
- We dont support this out of the box, but this seems like an interesting option. What you can do however is set an env var on the build machine to identify the site you are running the build on and modify the drop directory property accordingly. Please let me know if that works or if you hit any issues doing that.
- Here is the simplest hack. Since we support passing BuildDirectory, you can use that to create two different drop location. For example, the current entry in TFSBuild.proj looks like -
<
DropLocation>\\GAUTAMG6\drops</DropLocation>
Remove that line and add -
<
DropLocation Condition=" '$(BuildDirectoryPath)'=='D:\MySite1' ">\\MySite1Server\drops</DropLocation><
DropLocation Condition=" '$(BuildDirectoryPath)'=='D:\MySite2' ">\\MySite2Server\drops</DropLocation>
The the site 1 should pass D:\MySite1 as build directory in the UI (or command line) and site 2 should pass D:\MySite2.
Thanks,
Gautam - I have blogged this - http://blogs.msdn.com/gautamg/archive/2005/12/09/501952.aspx
All Replies
- We dont support this out of the box, but this seems like an interesting option. What you can do however is set an env var on the build machine to identify the site you are running the build on and modify the drop directory property accordingly. Please let me know if that works or if you hit any issues doing that.
- Dean,
Here is the sample code that may help you to.
using
System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Build.Utilities;
using Microsoft.Build.Framework;
namespace DifferentDropLocations
{
public class DifferentDropLocations : Task
{
private string dropLocation;
private string dropMachine;
public string DropMachine
{
get { return dropMachine; }
set { dropMachine = value; }
}[
Output]
public string DropLocation
{
get { return dropLocation; }
set { dropLocation = value; }
} public override bool Execute()
{
DropLocation = @"\\" + DropMachine + @"\Drops";
return true;
}
}
}I have set environment variable "DropMachine" on the build machine.
The value of the "DropMachine" is used to set the drop location
Here is how you use it in tfsbuild.proj
<
UsingTask AssemblyFile="DifferentDropLocations.dll" TaskName="DifferentDropLocations"/><
Target Name="BeforeEndToEndIteration">
<DifferentDropLocations DropMachine="$(DropMachine)">
<Output TaskParameter="DropLocation" PropertyName="DropLocation"/>
</DifferentDropLocations>
</Target> - Here is the simplest hack. Since we support passing BuildDirectory, you can use that to create two different drop location. For example, the current entry in TFSBuild.proj looks like -
<
DropLocation>\\GAUTAMG6\drops</DropLocation>
Remove that line and add -
<
DropLocation Condition=" '$(BuildDirectoryPath)'=='D:\MySite1' ">\\MySite1Server\drops</DropLocation><
DropLocation Condition=" '$(BuildDirectoryPath)'=='D:\MySite2' ">\\MySite2Server\drops</DropLocation>
The the site 1 should pass D:\MySite1 as build directory in the UI (or command line) and site 2 should pass D:\MySite2.
Thanks,
Gautam - I have blogged this - http://blogs.msdn.com/gautamg/archive/2005/12/09/501952.aspx
- I tried this approach:
<DropLocation Condition=" '$(BuildDirectoryPath)'=='D:\MySite1' ">\\MySite1Server\drops</DropLocation>
<
DropLocation Condition=" '$(BuildDirectoryPath)'=='D:\MySite2' ">\\MySite2Server\drops</DropLocation>
It doesn't appear to work for me. My first thought was that the BuildDirectoryPath property was not being evaluated correctly or in the wrong order or something. So I tried switching the order of the statements. The first one always gets picked no matter what. I also tried changing the BuildDirectoryPath property in the TFSProj file, but it doesn't make any difference. Next I tried the following:
<DropLocation Condition=" 'hello'=='hello2' ">\\MySite1Server\drops</DropLocation>
<
DropLocation Condition=" 'hello'=='hello' ">\\MySite2Server\drops</DropLocation>
The first condition is false but it picks that drop location anyway. From this, it seems that firing off Team Build inside VS probably overrides the DropLocation property on the command line. VS does examine the TFSProj file before bringing up the dialog box to start the build. If you leave the drop location blank, for example, you will get an error message and the build dialog won't appear. VS probably looks at the DropLocation property in the file (ignoring any condition) to form its command line statement. From reading the MSBuild docs, it says that command line props always override whatever is in the file.
Does this seem correct or have I made a silly error? Has anybody succeeded with this approach for conditional drop locations?
I haven't tried the coding approach yet. Will try it now.
Paul Yes, you are right. In Beta 3 we were redundantly passing the DropLocation. We fixed this sometime after Beta 3 and since I tried on my dev box which has latest build installed, it worked. Sorry about it. You will be able to use above approach in RTM.
For Beta 3, you can workaround this by overriding BeforeEndToEndIteration target. Add the following code (instead of the above one) in TFSBuild.proj and try again -
<Target Name="BeforeEndToEndIteration">
<!-- Drop location for site1 -->
<CreateProperty Value="\\MySite1Server\drops" Condition=" '$(BuildDirectoryPath)' == 'D:\MySite1' ">
<Output TaskParameter="Value" PropertyName="DropLocation" />
</CreateProperty>
<!-- Drop location for site2 -->
<CreateProperty Value="\\MySite2Server\drops" Condition=" '$(BuildDirectoryPath)' == 'D:\MySite2' ">
<Output TaskParameter="Value" PropertyName="DropLocation" />
</CreateProperty>
</Target>
This target will override the values passed by the build agent.
Sorry for the inconvenience.
Gautam


