好的，所以我的构建环境遇到了一些我想解决的问题。
我有一个解决方案文件，其中包含多个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将所有内容都转储到一个文件夹中， Unity程序集的Silverlight版本会覆盖非Silverlight版本，因为它们具有完全相同的程序集文件名。
然后当CruistControl运行我的单元测试时，它们会失败，因为它们不再具有适当的依赖项（它们尝试加载Silverlight特定的Unity程序集，这显然不起作用）。
所以我想做的是：
Idealy我希望MSBuild将所有内容放入类似于此的文件夹结构中：
nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc
我无法修改Unity项目以使其具有不同的文件名，因为它来自另一个我无法提交更改的SVN存储库。我在这里发现了一个类似的问题，建议的解决方案是使用“主”MSBuild文件，该文件使用自定义任务从解决方案中提取所有项目文件名，然后遍历构建它们的每个项目。我试过了，但它没有按照依赖关系的顺序构建它们，所以它对我的项目来说失败了。
帮助？
答案 0 :(得分：0)
首先，我总是让构建服务器删除旧的工作副本，并检查一个新的副本，以避免来自上一版本的陈旧工件的任何问题。
接下来，我会像以前一样构建解决方案，并将每个构建中的工件转到其本地工作输出文件夹。
之后我将工件从其工作路径移动到其输出路径，这不应该需要挖掘项目文件，因为您可以告诉msbuild / nant将working\project1\bin\release\**\*.*复制到{{1} }。
理想情况下，执行此操作的脚本应与源文件一起存储在主文件中，例如：在trunk的顶层构建.nant或build.proj。
答案 1 :(得分：0)
对于第三方库，我会简单地在您的存储库中包含DLLs目录。没有什么比写一些代码和第三方依赖更糟糕的了，因为他们的结果发生了变化。
只需记录您正在使用的库的版本，如果您必须更新它们，您就可以更好地了解在构建之前破坏构建的内容。
另外，CC.Net是否自动处理基于修订的版本提供？我正在使用TeamCity，它会保留每个构建的工件的副本。
我强烈推荐阅读JP Boodhoo的Automating Builds with NAnt博客系列。这是我的出发点，并根据自己的口味做了很多改变。我还强烈建议您查看许多开源项目的构建示例。我从Castle / Nhibernate / Rhino-Tools堆栈的构建中学到了很多东西。