5

背景

在我的职业生涯中，我惊讶地发现有多少项目在 Visual Studio 中编译和执行项目是一个真正的挑战。问题的根源通常是由于：缺少依赖项、缺少文档、损坏的项目引用等。

为了避免这些令人头疼的问题，我尝试自动化项目/解决方案，例如：

  1. 在开发人员机器上编译项目时会自动设置运行时环境（例如，使用批处理脚本导入缺少的 Windows 注册表项）
  2. 编译项目时，会自动检索正确的依赖项（在构建机器和开发机器上）

问题

迄今为止，我已经通过这种方法取得了相当大的成功。但是，我最近收到了一个依赖于 Microsoft Windows SDK 的本机 C++ 项目。在编译时，该项目使用 Windows 环境变量来定位缺失的依赖项（例如 Microsoft Windows SDK）。

我知道使用环境变量是过去的事情。但是，通过依赖软件开发人员来配置开发环境：

  • 您假设他们将正确配置环境
  • 开发人员在配置上浪费时间，而他们的时间可以更好地用于开发

我不想讨论让开发人员配置开发环境的优点，而是我想知道：

鉴于当今存在的技术（例如 TFS），在团队环境中处理 C++ 项目的大型依赖项（例如 Windows SDK）的可靠且可重复的方法是什么？

潜在的解决方案

  1. 继续使用环境变量
    • Adv：一旦安装了依赖项，构建机器就很容易编译项目
    • Dis：您必须花时间记录以确保您可以从头开始配置构建机器（例如步骤1：安装依赖项A，步骤2：安装依赖项B等）
    • Dis：您依靠神奇的环境变量来指向正确的目标。
    • 缺点：开发人员正在浪费时间配置他们应该开发的时间
  2. 将依赖项检查到 TFS
    • 进阶：一切都保存在一个集中的位置
    • 进阶：通过设计，源代码控制保留了历史
    • Adv：从某种意义上说，源代码控制使事情自我记录
    • Dis：现在在构建机器上编译需要相当长的时间，因为构建机器工作区必须反复从 TFS 检索 Windows SDK
  3. 其他？

语境

  • 编程语言：非托管 C++
  • 源代码控制：TFS 2012
  • 依赖项：
    • Microsoft Windows SDK (~416Mb)
    • 内部图书馆
  • 我对如何管理/配置 TFS 构建机器的知识有限。

参考

4

1 回答 1

1

我记得在一家安全公司工作时，团队有一个脚本，通常会在您点击编译后立即将所有依赖项复制到您的特定文件夹中。但是，对于 MFC 项目，它的 in build 属性让我感到困惑。

参考似乎很有帮助，谢谢

于 2013-06-19T14:34:26.180 回答