MSBuild覆盖依赖项

好的，所以我的构建环境有一个比较复杂的问题，我正试图处理这个问题

我有一个解决方案文件，其中包含多个C#项目，该项目由一个NAnt脚本生成，该脚本调用MSBuild，并将解决方案文件的名称和二进制文件复制到的路径传递给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将所有内容转储到单个文件夹中，Unity程序集的Silverlight版本将覆盖非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文件，该文件使用一个自定义任务从解决方案中提取所有项目文件名，然后循环每个项目文件名。我试过了，但是它没有按照依赖关系的顺序构建它们，所以我的项目失败了

---

帮助？

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

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

在此之后，我将工件从其工作路径移动到其输出路径，这不需要挖掘项目文件，因为您可以告诉msbuild/nant将

working\project1\bin\release\***.

复制到

artifacts\project1\

---

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

对于第三方库，我只需在存储库中包含DLL目录。没有什么比编写一些代码并让第三方依赖关系因为其端部的更改而破坏您的构建更糟糕的了

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

另外，CC.Net不会自动处理基于修订版的发布吗？我使用的是TeamCity，它保存了每个构建的工件的副本

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