这是上一个问题I have asked
的延续问题我现在在项目树的根目录中有一个/ externals目录。在这里我有一个参考另一个项目。我能够在主项目NAnt脚本中编写所有外部脚本的脚本。这些构建的结果如下：
/外部对象/外部PROJECT1 /建造/ buildartifacts / {的DLL | HTML | JS}
/外部对象/外部项目2 /建造/ buildartifacts / {的DLL | HTML | JS}
这一切都很好，但现在我很好奇我的主项目应该如何引用这些构建工件。例如，假设外部项目构建了一些我的代码库所依赖的DLL。我应该简单地引用构建工件目录中的DLL，还是应该实现另一个将这些复制到/ thirdparty / libs /文件夹的NAnt任务？
这意味着我的构建现在依赖于构建此外部项目的能力（可以是内部项目，也可以是第三方）。检查最新的构建工件集是否是一个好主意，以确保主构建不会因依赖构建中断而中断？
希望足够清楚。写下来对我来说问题最少： - ）。
- 编辑 -
谢谢你们。我想我将实施“结帐修订”，但由于构建速度很快，我不打算检查任何构建工艺。还需要弄清楚如何处理外部项目的依赖关系（例如：prototype，swfobject等）。
答案 0 :(得分：1)
我会说构建它们一次并检查/ public / ext / some_dependency / ref中的构建工件（显然，该文件夹的命名取决于你:-)）并从那里引用它们。
我的主要原因是，每次构建产品时，很少需要构建外部依赖项。通常，外部依赖性应该很少改变。此外，您需要严格控制何时选择外部依赖项更改，以避免在编码阶段引入不稳定性。
作为对此的扩展，我将添加一个单独的CI任务，该任务仅构建外部依赖项，并在某些外部条件下在上述文件夹中检查它们 - 依赖项源文件夹中的提交或其他内容。
答案 1 :(得分：1)
我提出的一个建议（我认为它来自Mike Mason的实用版本控制书）来引用外部的特定修订版，以便您始终获得相同版本的外部依赖项，直到您明确选择改变它。
此时，您可能已经交互式地构建了一次以确保它正常工作，因此每次依赖它来构建并不是真正的问题，这避免了在构建任务中添加一些间接的需要。
如果您选择间接，并且出于某种原因，构建在外部上失败，则可能会错过，因为下一个nant任务将获取前一个二进制文件。