property evaluation order (beta 3)

I just tried this on my machine, and it behaves in the same manner. I'm using the December CTP of TFS. 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.

Hope this helps,

Sayed Ibrahim Hashimi
www.sedodream.com

SayedIbrahimHashimi at 2007-9-9 >

Hi Folks,

I am also trying to do something similar.

I currently use the incremented version number (ie 1.3.0.2345) in the following manner:

• label my source code
• update assemblyinfo.cs, files
• as the $(projectName) \$(versionNumber) drop location

In using TFSBuild.exe I cannot change the Build Name or the Drop Location at any point in the tfsbuild.proj file.

The build log only reflects what TFSBuild.exe forces upon the user:

Target InitializeEndToEndIteration:
UpdateBuildNumberDropLocation BuildNumber='Auto_20060410.9' DropLocation='\\TFSBUILD\Share\Auto_20060410.9' .

Is there (or will there be) a way to change/ignore this behaviour through parameters to TFSBuild.exe?

A second issue ...

Why does the GET grab everything from the project directory on down, including the BuildTypes subdirectory structure? Is there a way to "cherry-pick" the directories we want to use?

MSBuild offers the flexability to do all of these and TFSBuild removes this flexability. Is there a way to update the TFSBuild reporting summary without using TFSBuild?

Regards,

Sean

SeanPerkin at 2007-9-9 >

Thanks Manish. That helped.

I currently use the incremented version number (ie 1.3.0.2345) in the following manner:

• label my source code
• update assemblyinfo.cs, files
• as the $(projectName) \$(versionNumber) drop location

In using TFSBuild.exe I cannot change the Build Name any point in the tfsbuild.proj file

Is it possible to change the build name to be the same as the version number?

Is there a way to update the TFSBuild reporting summary without using TFSBuild?

Regards,

Sean

SeanPerkin at 2007-9-9 >

Sean,

Can you give some more details on what kind of fields or information that are looking to update in the Team Build Report?

Thanks,
Amit

AmitChattopadhyay at 2007-9-9 >