哦麻煩了。 Visual Studio 2003 和 Cruise Control.NET。簡單又優雅。用於建立解決方案的基本 NAnt 腳本就可以開始了。運行 NUnit，輸出採用 CC 和 Bob 的叔叔可以理解的格式。讓我量化一下。我們的 Cruise 伺服器有一個 Subversion 客戶端（命令列）和 .NET 1.1 SDK。未安裝 Visual Studio，因為，呃，它是一個伺服器，而 Cruise 只需要一些東西來建立系統。
進入 Visual Studio 2005。首先嘗試使用 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 美元的軟體當有一天找不到某個註冊表項時彈出一個模式對話框。
咕嚕。啊。