如何弥补开发机和构建服务器之间的环境差异？
我将 NUnit 安装在我的计算机上的“C:\Program Files\NUnit 2.4.8\”中，但在我的集成服务器（运行 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 安装在与集成服务器中相同的位置？ 这个解决方案对我来说似乎限制太多。 还有更好的吗？ 解决此类问题的一般方法是什么？
I have NUnit installed on my machine in "C:\Program Files\NUnit 2.4.8\" but on my integration server(running CruiseControl.Net) I have it installed in "D:\Program Files\NUnit 2.4.8\". The problem is that on my development machine my NAnt build file works correctly because in the task I'm using the path "C:\Program Files\NUnit 2.4.8\bin\NUnit.Framework.dll" to add reference to the 'NUnit.Framework.dll' assembly but this same build file cannot build the file on my integration server(because the reference path is different). Do I have to have my NUnit installed at the same location as it is in my integration server? This solution seems too restrictive to me. Are there any better ones? What is the general solution to this kind of problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
通常，我将 NUnit 和任何其他依赖项与我的项目分发到某个公共位置（对我来说，这是顶层的 libs 目录）。
然后，我只需从应用程序中引用这些库，并且它们始终位于相对于项目解决方案的相同位置。
Typically I distribute NUnit and any other dependencies with my project, in some common location (for me that's a libs directory in the top level).
I then just reference those libs from my application, and they're always in the same location relative to the project solution.
一般来说，应该避免对绝对路径的依赖。 就 CI 而言，您应该能够仅使用通过自动化脚本在源代码控制中找到的资源，在干净的机器上完全从 scatch 构建和运行您的解决方案。
In general, dependencies on absolute paths should be avoided. As far as CI goes, you should be able to build and run your solution on a clean machine completely from scatch using only resources found in your source code control via automated scripts.
“最终”解决方案可以是将整个工具链存储在源代码管理中，并存储您在源代码管理中构建的任何库/二进制文件。 正确设置，这可以确保您能够从任何时间点重建任何版本，与发布时完全相同，但此外，您不需要这样做，因为您生成的每个二进制文件都是源头控制。
然而，要达到这一点是一项艰巨的工作。
The "ultimate" solution can be to have the entire tool-chain stored in your source-control, and to store any libraries/binaries you build in source-control as well. Set up correctly, this can ensure you have the ability to rebuild any release, from any point in time, exactly as it was shipped, but that, furthermore, you don't need to do that as every binary you#ve ever generated is source-controlled.
However, getting to that point is some serious work.
我会使用两种方法：
1）使用具有不同路径的两个不同的暂存脚本（开发构建/集成构建）。
2）将所有需要的可执行文件放入您的路径文件夹中并直接调用它们。
I'd use two approaches:
1) use two different staging scripts (dev build/integration build) with different paths.
2) put all needed executables in you path folder and call them directly.
我同意绝对路径是邪恶的。 如果您无法绕过它们，您至少可以在脚本中设置一个 NUNIT_HOME 属性（默认为 C:...），并在 CI 服务器中调用在命令行传递 NUNIT_HOME 属性的脚本。
或者，您可以将脚本设置为需要设置 NUNIT_HOME 环境变量才能使 NUNIT 正常工作。 现在，您的脚本不再要求其运行的计算机在某个确切位置具有 nUnit，而是要求 nunit 在环境变量中存在并可用。
这两种方法都允许您更改正在使用的 nunit 版本，而无需修改构建脚本，这是您想要的吗？
I'd agree that absolute paths are evil. If you can't get around them, you can at least set an NUNIT_HOME property within your script that defaults to C:... and in your CI server call your script passing in the NUNIT_HOME property at the command line.
Or you can set your script to require an NUNIT_HOME environment variable to be set in order for NUNIT to work. Now, instead of requiring that the machine it runs on has nUnit in some exact location, your script requires that nunit be present and available in the environment variable.
Either approach would allow you to change the version of nunit you are using without modifying the build script, is that what you want?
将工具链中的所有工具置于版本控制之下的想法是一个很好的想法。 但是，在您的路径上，您可以使用几种不同的技术来为每台计算机指定不同的路径。
Nant 让您定义一个
，您可以使用-Dname=value覆盖。 您可以使用它为您的开发机器设置一个默认位置，并在 CI 系统中覆盖该默认位置。您还可以使用
获取环境变量的值environment::get-variable更改每台机器的位置。The idea of having all the tools in the tool chain under version control is a good one. But while on your path there you can use a couple of different techniques to specify different paths per machine.
NAnt let's you define a
<property>that you can override with-Dname=value. You could use this to have a default location for your development machines that you override in your CI system.You can also get values of environment variables using
environment::get-variableto change the location per machine.