哦麻烦了。 Visual Studio 2003 和 Cruise Control.NET。简单又优雅。用于构建解决方案的基本 NAnt 脚本就可以开始了。运行 NUnit，输出采用 CC 和 Bob 的叔叔可以理解的格式。让我量化一下。我们的 Cruise 服务器有一个 Subversion 客户端（命令行）和 .NET 1.1 SDK。未安装 Visual Studio，因为，呃，它是一个服务器，而 Cruise 只需要一些东西来构建系统。
进入 Visual Studio 2005。我最近刚刚为我们的 2005 项目设置了 CI，但它在很多方面都非常丑陋。首先尝试使用 MSBuild 构建系统。这很好，因为你可以简单地输入：
msbuild /t:rebuildsolutionname.sln
（或任何你想要的目标，如调试或发布）
就像我说的，如果这就是全部，那就没问题了，但它很快就会变得非常丑陋。
首先是 VSTS 单元测试项目。团队全部配备了Visual Studio Team Suite。这是一个昂贵的提议，但却是很久以前由比我更聪明的人提出的。不过没问题。我们并没有真正使用太多测试管理器，没有自动化的 Web 测试，因此我们只是编写单元测试（并使用 Jamie Cansdales 优秀的 TestDriven.NET 运行它们）。然而，当 MSBuild 获得包含 VS 单元测试项目的解决方案时，它需要一些额外的程序集（埋在 GAC_MSIL 和其他位置的程序集）。 ccnet.config 文件中用于启动 MSBuild 的代码片段非常简单：
<msbuild>
<可执行文件>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</可执行文件>
<工作目录>D:ccnetprojects项目名称</工作目录>
<项目文件>解决方案名称.sln</项目文件>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<目标>构建</目标>
<超时>600</超时>
<logger>C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
通过强力（运行 MSBuild，找出它需要什么程序集，找到它，起泡沫，冲洗，重复），我能够得到一个 2005 解决方案（带有单元测试项目）进行编译。然而，实际运行测试是另一回事。当我运行 MSTest.exe 一两个小时，试图诱使数百个单元测试运行时，暴力再次占据了主导地位。用于获取一些单元测试的 cc.config 条目如下所示：
<exec>
<可执行文件>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe</可执行文件>
<baseDirectory>d:ccnetprojectsProjectName</baseDirectory>
<buildArgs>/testcontainer:SourceTestsUnitTestsbinAutomatedBuildUnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>
请记住，我说过该服务器没有安装 Visual Studio。对于 VS2005 解决方案，我刚刚安装了 .NET SDK 2.0，这已经足够了。虽然不包括 MSTest.exe，但我从另一个系统中获取了该文件（它是一组疯狂的附加 DLL，分散在整个硬盘驱动器上）并将其固定在 EXE 所在的位置，这样它会很高兴。
针对单元测试项目运行 MSTest 没有任何风险。它开始沿着运行测试的路径，但随后遇到了一个疯狂的 COM 错误（CLSID 未注册），这对我来说已经足够了。我不可能找出 Visual Studio 2005 的所有愚蠢的 COM 注册表设置。这到底是什么？ COM？我以为我们在大约 3 个编译器之前就摆脱了它？
所以我不得不在服务器上安装完整的团队套件。好吧，我咬一下。我的意思是，我不需要一切，所以一切都会好起来的（当我看到一百万个注册表项被填满时，我不断告诉自己）。几个小时后，我再次盯着命令提示符并输入 MSTest.exe 命令。并弹出一个对话框。是的，一个模式对话框告诉我出了什么问题（我不记得具体细节，但信息不多）。
Visual Studio 安装得很好，我可以编译、运行并构建我想要的解决方案，但使用 MSTest.exe 从命令行进行测试是不行的。无论我如何努力，如何清理，或者牺牲多少处女，它都不会过去。还有另一个问题。通过 2003 年和我们的 NUnit 测试，我们得到了一些不错的统计数据。时间安排、信息丰富的消息，所有这些好东西。使用 MSTest，我们什么也得不到（除了运行了 x 次测试并且可能失败，但我无法了解它是否会给出失败的详细信息）。最重要的是，MSBuild 记录器会产生大约 10,000 行不太有用的冗长的代码。是的，我可以花时间编写新的 xslt 以使其美观，删除填充 MSBuild 任务记录器的“一切都很好”行，但我认为按照我的速度，这并没有增值。
这是我从构建中收到的示例电子邮件，它让您了解 CC.NET/MSBuild/MSTest 组合是多么无用：
构建成功
项目：项目名称
构建日期：2006 年 12 月 8 日上午 8:08:30
运行时间：00:00:55
集成请求：intervalTrigger 触发了构建 (ForceBuild)
错误 (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1)：错误 MSB4041：项目的默认 XML 命名空间必须是 MSBuild XML 命名空间。如果项目是以 MSBuild 2003 格式编写的，请将 xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " 添加到 <Project> 中。元素。如果项目是以旧的 1.0 或 1.2 格式编写的，请将其转换为 MSBuild 2003 格式。
警告 (1)
SourceReportsServerReportsServerReports.rptproj (,)：警告 MSB4122：扫描项目“SourceReportsServerReportsServerReports.rptproj”的项目依赖项失败。项目的默认 XML 命名空间必须是 MSBuild XML 命名空间。如果项目是以 MSBuild 2003 格式编写的，请将 xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " 添加到 <Project> 中。元素。如果项目是以旧的 1.0 或 1.2 格式编写的，请将其转换为 MSBuild 2003 格式。 D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
测试运行：0，失败：0，未运行：0，时间：0 秒
没有运行测试
该项目没有任何测试
自上次构建以来的修改 (0)
太丑了。真的很丑。 MSBuild 产生大量疯狂的输出。编写新的 MSBuild 文件可不是在公园里散步，即使对于像我这样非常了解 NAnt 的人来说，我仍然对 MSBuild 的工作原理很困惑。我必须在 Visual Studio 内部创建一个特殊的配置来省略我们的 Report 项目，因为 MSBuild 无法构建它们（因此上面的目标 AutomatedBuild 与我们的开发人员使用的配置不同，也是我不喜欢做的事情，因为这是一个CI 服务器的点，为每个人提供一致的构建）。
从上面的输出来看，Cruise 表示构建没问题，但 MSBuild 记录器（我们的报告项目）中出现了一条错误消息。这是一个 2005 年的项目，所以这些信息没有任何意义（我相信这是一个已记录的错误，但谁知道它什么时候会得到修复）。我真的无法将 MSTest 输出集成到电子邮件中，因为没有。该项目中有大约一百个测试，但记录器不会产生任何结果。
此外，有些项目类型 MSBuild 无法处理，而且需要火箭科学家才能创建一个 MSBuild 文件（甚至使用像 MSBuild Sidekick 这样很酷的东西），该文件可以调用另一个 MSBuild 任务并排除某些项目。这当然不像 2003 年那么容易，当时您刚刚创建了一个排除列表（我们排除了我们的客户端应用程序，因为网格控件没有额外的许可证，并且当试用版甚至被查看时会出现一个模式对话框）编译器）。
好吧，这主要是一种咆哮，但这里有一些智慧。持续集成不需要这么难。 CruiseControl.NET 是一个优秀的工具，并且非常灵活地使用新工具并集成这些工具的输出。然而，当这些工具需要一百万个注册表设置和更多的 DLL（放在非常具体的位置，相信我，你不能只是将它们扔到 GAC 中然后就到此为止）并转储大量 XML 时，这些 XML 并不是凡人（好吧）也许 DonXml 可以）能够翻译，但这是错误的。至于您可以使用的内置 Team Build，这同样无用，因为 a) 您无法安排构建来触发代码签入，b) 再次需要在服务器上安装完整的 Team Suite 客户端。最糟糕的情况是，当我第一次开始设置 CC.NET 服务器时，花了 4 个小时。现在我可以在一小时内完成它（包括测试第一个项目的构建）。我已经花了美好的一天来尝试编译一些东西。它现在正在编译，但输出很糟糕，并且没有运行测试，这对我来说还不够好。您可以使用 CruiseControl.NET 运行 MSBuild 和（也许）MSTest。这并非不可能。如果你安装了完整的客户端并且你的项目“恰到好处”，它会工作，但输出不是那么热，并且当编译发生时你会看到你的服务器 CPU 崩溃。
我的建议是，避免尝试组合 MSBuild、MSTest 和 CruiseControl，而坚持使用 NAnt 和 NUnit（如果在构建 2005 解决方案时必须使用 MSBuild）。
不用说，我现在正在考虑一种选择。将 VS2005 的安装转储到服务器上，将所有单元测试更改回 NUnit 并使用 NAnt 执行所有操作（仅调用 MSBuild 作为 VS2005 项目的执行任务）。我仍然需要运行 2003 项目，所以当我完成构建 VS2003 和 VS2005 项目、运行 NUnit、MSBuild、NAnt、Simian、FxCop 以及我们的其他项目时，我们的 CI 服务器将看起来像弗兰肯斯坦怪物。混合。即使如此，使用 NAnt 输出会更简单（并且与 CC.NET 集成良好），测试输出将是有用且信息丰富的，而且我不需要在具有明显可能性的服务器上安装价值 15,000 美元的软件当有一天找不到某个注册表项时弹出一个模式对话框。
咕噜。啊。