2

我在“C:\Program Files\NUnit 2.4.8\”的机器上安装了 NUnit，但在我的集成服务器（运行 CruiseControl.Net）上，我将它安装在“D:\Program Files\NUnit 2.4.8\”中. 问题是在我的开发机器上我的 NAnt 构建文件可以正常工作，因为在任务中我使用路径“C:\Program Files\NUnit 2.4.8\bin\NUnit.Framework.dll”来添加对'的引用NUnit.Framework.dll' 程序集，但这个相同的构建文件无法在我的集成服务器上构建文件（因为引用路径不同）。我是否必须将 NUnit 安装在与集成服务器相同的位置？这个解决方案对我来说似乎太严格了。有没有更好的？这类问题的一般解决方案是什么？

4

6 回答 6

4

通常，我将 NUnit 和任何其他依赖项与我的项目一起分发到某个公共位置（对我来说，这是顶层的libs目录）。

/MyApp
  /libs
    /NUnit
    /NAnt
    /etc...
  /src
    /etc...

然后，我只需从我的应用程序中引用这些库，它们相对于项目解决方案始终位于相同的位置。

于 2008-12-23T14:17:34.503 回答
1

通常，应避免对绝对路径的依赖。就 CI 而言，您应该能够在干净的机器上完全从 scatch 构建和运行您的解决方案，只使用通过自动化脚本在源代码控制中找到的资源。

于 2008-12-23T14:19:24.110 回答
1

“终极”解决方案可以是将整个工具链存储在您的源代码控制中，并存储您在源代码控制中构建的任何库/二进制文件。正确设置，这可以确保您能够从任何时间点重建任何版本，与发布时完全相同，但此外，您不需要这样做，因为您生成的每个二进制文件都是源头控制。

然而，达到这一点是一项严肃的工作。

于 2008-12-23T14:21:29.270 回答
0

我会使用两种方法：

1）使用具有不同路径的两个不同的暂存脚本（开发构建/集成构建）。

2）将所有需要的可执行文件放在你的路径文件夹中并直接调用它们。

于 2008-12-23T14:18:09.137 回答
0

我同意绝对路径是邪恶的。如果您无法绕过它们，您至少可以在您的脚本中设置一个默认为 C:... 的 NUNIT_HOME 属性，并在您的 CI 服务器中调用您的脚本，在命令行中传递 NUNIT_HOME 属性。

或者，您可以将脚本设置为需要设置 NUNIT_HOME 环境变量才能使 NUNIT 工作。现在，您的脚本不要求运行它的机器在某个确切位置具有 nUnit，而是要求 nunit 在环境变量中存在且可用。

任何一种方法都允许您更改正在使用的 nunit 版本，而无需修改构建脚本，这是您想要的吗？

于 2008-12-23T14:58:33.563 回答
0

将工具链中的所有工具都置于版本控制之下的想法是一个很好的想法。但是，在您的路径上，您可以使用几种不同的技术来指定每台机器的不同路径。

NAnt 让您定义一个<property>可以覆盖的-Dname=value. 您可以使用它为您在 CI 系统中覆盖的开发机器设置默认位置。

environment::get-variable您还可以使用更改每台机器的位置来获取环境变量的值。

于 2008-12-23T15:31:59.533 回答