我可以覆盖 DropLocation 目标以避免网络延迟吗？答案

【问题标题】：Can I override DropLocation target to avoid network latency?我可以覆盖 DropLocation 目标以避免网络延迟吗？
【发布时间】：2008-11-24 15:23:42
【问题描述】：

在 Team Build 2008 中，构建的放置位置不再在 .proj 文件中指定，而是存储在数据库中并在 GUI 工具中维护。

GUI 工具仅接受网络路径作为放置位置（即 \\server\share），不接受本地路径。

我们的构建服务器还托管删除的文件，因此在复制大量文件时，强制文件复制操作通过网络共享似乎会引入很多延迟时间。我想覆盖此功能，以便为放置位置指定本地目录，但我不知道如何。

【问题讨论】：

标签： tfs msbuild tfsbuild

【解决方案1】：

我没有使用 2008 版本，只有 2005 版本，但您似乎可以手动执行此操作。将 SkipDropBuild 属性设置为 true。然后使用 Team Build 内置的 Copy 命令在 BeforeDropBuild 事件中手动复制所有二进制文件。

类似这样的：

<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>

【讨论】：

【解决方案2】：

我找到了一个更简单的解决方案，那就是在 Release 文件夹上执行一个文件系统move。由于放置位置实际上位于同一个物理驱动器上，我可以接受。我已将此添加到 TFSBuild.proj 文件中：

<Target Name="CoreDropBuild"
        Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
        DependsOnTargets="$(CoreDropBuildDependsOn)" >
    <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>
</Target>

【讨论】：

仅供参考 - 您应始终避免覆盖“核心”目标，因为这可能会在 Microsoft 发布 TeamBuild .targets 文件的新版本（即在服务包中）时导致问题。最好按照 Todd 的建议设置 SkipDropBuild 属性并将您的逻辑放在 BeforeDrop 或 AfterDrop 中。 .targets 文件包含的文档告诉您 Microsoft 打算让您覆盖哪些目标。

【解决方案3】：

实际的 BuildDropLocation 需要在网络共享上可用。发布测试结果时，客户端和 TFS 应用程序层将使用放置位置。在访问构建结果时，客户端和 TFS 应用程序层机器也需要可以访问它。作为数据仓库步骤的一部分，TFS 应用程序层机器将通过放置位置访问构建结果，以查找要添加到仓库的测试结果文件。

也就是说，假设您的构建服务器是托管您的放置位置共享的同一台机器 - 并且始终是同一台机器，那么您可以跳过 TFSBuild.proj 中的放置步骤。一种解决方案可能是Todd 和Chad 所概述的组合，例如：

<SkipDropBuild>true</SkipDropBuild>
<Target Name ="AfterDropBuild">
        <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>
</Target>

请注意，您实际上不必对“发布”部分进行硬编码，而是能够从配置属性中获取该部分 - 但是我手头没有 TeamBuild 目标文件，因此我无法确切说明那是什么是现在，所以当我回到我的办公桌时会查找它并相应地编辑此答案。

也就是说，这样做涉及很多风险。

您必须确保所有文件路径排列正确，否则查看构建日志或使用测试结果填充 TFS 仓库等操作可能会停止工作
您将硬编码构建和放置位置以始终存在于同一台计算机上。如果有人试图在另一台机器上构建您的 TFSBuild.proj 文件，那么事情将无法按预期进行
如果有人在构建定义中编辑放置位置属性，那么他们必须知道在 TFSBuild.proj 文件中进行相应的编辑

因此，由于这种方法涉及可维护性问题 - 在绝大多数情况下，我不会推荐它。值得做一个测试，看看这实际上节省了多少时间，以确定在您的情况下它是否值得进行优化。

【讨论】：