MSBuild 覆盖依赖项答案

【问题标题】：MSBuild overwriting dependenciesMSBuild 覆盖依赖项
【发布时间】：2009-08-25 23:04:21
【问题描述】：

好的，我正在尝试处理的构建环境有一个有点复杂的问题。

我有一个包含多个 C# 项目的解决方案文件，该项目由调用 MSBuild 的 NAnt 脚本构建 - 向 MSBuild 传递解决方案文件的名称和将二进制文件复制到的路径。这是因为我希望我的自动构建环境 (CruiseControl.Net) 创建一个以每个构建的修订版命名的文件夹 - 这样我可以轻松地以任何原因返回到以前的二进制文件。

所以理想情况下我有这样的文件夹布局

c:\build\nightly\rev1
c:\build\nightly\rev2
c:\build\nightly\rev3
...
c:\build\nightly\rev10
etc.

出现的问题是我最近将最新版本的 Unity IoC 容器添加到我的项目中，直接从 MS 的在线 SVN 存储库中检查它。发生的事情是我有一个 Silverlight 3 项目，它引用了 Unity 的 Silverlight 版本，但我还有其他项目（即我的单元测试项目）引用了 Unity 的标准（非 Silverlight）版本。

因此，由于 MSBuild 将所有内容转储到一个文件夹中，Silverlight 版本的 Unity 程序集将覆盖非 Silverlight 版本，因为它们具有完全相同的程序集文件名。

然后当 CruistControl 运行我的单元测试时，它们会失败，因为它们不再具有可用的适当依赖项（它们尝试加载 Silverlight 特定的 Unity 程序集，这显然不起作用）。

所以我想做的是：

保留我想要的输出目录结构（文件夹\修订）
我不想手动编辑我拥有的每个项目文件添加新的时容易出错项目解决方案

理想情况下，我希望 MSBuild 将所有内容放入类似于以下的文件夹结构中：

nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc

我不能修改 Unity 项目来给它一个不同的文件名，因为它来自另一个我无法提交更改的 SVN 存储库。我在这里发现了一个类似的问题，建议的解决方案是使用“主”MSBuild 文件，该文件使用自定义任务从解决方案中提取所有项目文件名，然后遍历每个构建它们的文件名。我试过了，但它没有按照它们的依赖顺序构建它们，所以我的项目失败了。

帮助？

【问题讨论】：

标签： msbuild

【解决方案1】：

首先，我总是让构建服务器删除旧的工作副本并签出一个新副本，以避免之前构建的陈旧工件出现任何问题。

接下来，我会让 nant 或 msbuild 像以前一样构建解决方案，每个构建中的工件都进入它们的本地工作输出文件夹。

之后我会将工件从它们的工作路径移动到它们的输出路径，这不应该需要挖掘项目文件，因为您可以告诉 msbuild/nant 将 working\project1\bin\release\**\*.* 复制到 artifacts\project1\。

理想情况下，执行此操作的脚本应与主文件的源一起存储，例如build.nant 或 build.proj 在主干的顶层。

【讨论】：

【解决方案2】：

对于第三方库，我会简单地将 DLLs 目录包含在您的存储库中。没有什么比编写一些代码并让第三方依赖项因最终更改而破坏您的构建更糟糕的了。

只需记录您正在使用的库的版本，如果您必须更新它们，您甚至可以在签入之前更好地了解是什么破坏了构建。

另外，CC.Net 不是自动处理基于修订的版本的提供吗？我正在使用 TeamCity，它会保留每个构建的工件的副本。

我强烈推荐阅读 JP Boodhoo 的 Automating Builds with NAnt 博客系列。这就是我的出发点，并为我自己的口味做了很多改变。我还强烈建议您查看许多开源项目的构建以获取示例。我从 Castle/Nhibernate/Rhino-Tools 堆栈的构建中学到了很多东西。

【讨论】：