Can I override the DropLocation target to avoid network latency?
In Team Build 2008, the Drop location for the build is no longer specified in the .proj file and is instead stored in the database and maintained in the GUI tool.
The GUI tool only accepts the network path as the drop location (i.e. \\ server \ shared) and does not accept the local path.
Our build server also stores dropped files, so it seems like forcing a file copy operation over a network share results in a long delay when copying a large number of files. I would like to override this function so that I can specify the local directory for the drop location, but I cannot figure out how.
source to share
I haven't worked with the 2008 version only the 2005 version, but it looks like you can do it manually. Set the SkipDropBuild property to true. Then copy all binaries manually into the BeforeDropBuild event using the Copy command built into Team Build.
Something like that:
<SourceDir>$(SolutionRoot)\..\Binaries\Release</SourceDir>
<SkipDropBuild>true</SkipDropBuild>
<CreateItem Include="$(SourceDir)\**\*.*">
<Output TaskParameter="Include" ItemName="BuiltBinaries"/>
</CreateItem>
<Target Name ="BeforeDropBuild">
<Copy SourceFiles="@(BuiltBinaries)" DestinationFiles="@(BuiltBinaries->'C:\droplocation\%(Filename)%(Extension)')"/>
</Target>
source to share
I found an easier solution, namely simply moving the filesystem to the Release folder. Since the drop location is actually on the same physical disk, I'm fine with that. I added this to the TFSBuild.proj file:
<Target Name="CoreDropBuild"
Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
DependsOnTargets="$(CoreDropBuildDependsOn)" >
<Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>
</Target>
source to share
The actual BuildDropLocation value must be available on the network share. The dropdown location is used by clients and the TFS application layer when publishing test results. It also needs to be available to both clients and the TFS Application Tier machine when accessing build results. As part of the datawarehouse phase, the TFS Application Tier will access the build results above the drop location to locate the test result files to add to the warehouse.
However, assuming that your build server is the same computer that hosts your location resource, and will always be the same computer, you can skip the transition from TFSBuild.proj. One solution is likely to be a combination of those described by Todd and Chad , for example:
<SkipDropBuild>true</SkipDropBuild>
<Target Name ="AfterDropBuild">
<Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>
</Target>
Note that you don't actually need to hard-code the "Release" part, but be able to get that from the config properties, however I don't have a TeamBuild target file so I can't tell exactly which at this point, so I'll go over its when I return to my desk and edit this answer accordingly.
However, there are many risks associated with this.
- You have to make sure all file paths are lined up exactly to the right, or something like looking at the build log or filling the TFS storage with test results might stop working.
- You will have hardcoded build and delete locations that always exist on the same machine. If someone tries to create your TFSBuild.proj file on a different machine, then things won't work as they expect.
- If someone is editing the drop location property in the build definition, then they need to know to make the corresponding edit in the TFSBuild.proj file.
Therefore, due to the maintainability issues associated with this approach, I would not recommend it in the vast majority of cases. It would be wise to run a test and see how much time this actually saves to determine if this is a worthwhile optimization in your circumstances.
source to share