在 TFS 构建代理上引用第 3 方库和标头答案

【问题标题】：Referencing 3rd party libraries and headers on a TFS build agent在 TFS 构建代理上引用第 3 方库和标头
【发布时间】：2015-02-10 02:43:35
【问题描述】：

到目前为止，我们的团队一直在使用 VSS，我们正处于迁移到 TFS2010 和 VS2010 的过程中。我们的大部分代码是 C++，我们使用了很多 3rd 方库，例如 Boost、OpenCV、OpenSSL 等。根据我阅读的最佳实践，我正在考虑在我们的多个解决方案和项目中处理 3rd 方标头和库的一些选项。

我为所有第 3 方库创建了一个独立的 TFS 项目，并在每个库和每个版本中存储源/包含/输出。例如：

Dependencies\
  -> Boost\
         ->boost_ver1\*
         ->boost_ver2\*
  -> OpenSSL\
         ->openssl-ver1\*
         ->openssl-ver2\**

我的 TFS 源代码树如下所示：

$\
    -> Dependencies\
    -> TeamProject1\
    -> TeamProject2\
    -> TeamProject3\

我们的 TeamProject(s) 可能包含文件夹树中不同级别的多个解决方案。
我为每个团队项目准备了一个 dependencies.props 文件，给定团队项目的所有项目都导入到该文件中。该 .props 文件将相关的第 3 方包添加到 $(IncludePath) 和 $(LibraryPath)。为了做到这一点，我假设 Dependencies 项目被映射到一个由每个用户每台机器的全局环境变量定义的文件夹。

我对这种方法有几个问题：

我不知道如何使它在构建代理上工作，因为我无法在构建定义的工作区映射选项卡中指定环境变量。我了解每次构建都会更改 BuildDirectory var 和 SourceDir var。
如何确保在开始构建任何 TeamProject 解决方案之前获得最新的相关第三方依赖项。
这是一个“好”的方法吗？

【问题讨论】：

NuGet 应该会在接下来的几个月内获得原生 c++ 支持，如果你能等那么久的话。但是我想指出的是，通常建议不要在 TFS 中将项目拆分为他们自己的团队项目，除非你有充分的理由 (blog.hinshelwood.com/one-team-project)
Betty，我更喜欢使用多个团队项目，因为我们有非常不同的发布时间安排和许多构建要处理。

标签： tfsbuild

【解决方案1】：

1：如果您希望构建确定构建定义本身所需的依赖项集，您可以使用 msbuild 参数或 powershell 参数将参数传递给您的流程模板。只要通用依赖项和该文件包含在您的工作区中，您还可以让您的逻辑从您的 props 文件中提取信息。

2：只要在构建定义中映射了包含依赖项的源代码控制路径，它就会在构建您的解决方案之前从源代码控制同步最新版本，并在构建解决方案之前拥有它们。

3：不是特别适合您的情况。我建议不要使用通用依赖项区域，因为如果您执行门控构建之类的操作，您将在门控签入窗口中弹出所有 3 个构建。此外，对一种解决方案的更改可能会无意中影响所有三种解决方案。您是否考虑过使用nuget？这可能是保持您的 3 个解决方案分开并且还具有可供部分或全部使用的依赖项的最佳实践。例如，大多数编码工作的最常见依赖项都有可下载的 nuget 包，这些包将在构建期间下载，甚至无需签入。

【讨论】：