MSBuild, NAnt, NUnit, MSTest所带来的不爽

Oh bother. Visual Studio 2003 and Cruise Control.NET. Simple and elegant. A basic NAnt script to build the solution and you're good to go. Run NUnit, output goes to a format CC can understand and Bob's yer uncle. Let me quantify this. Our cruise server has a subversion client (command line) and the .NET 1.1 SDK. Visual Studio isn't installed because, duh, it's a server and cruise just needs something to build the system with.

Enter Visual Studio 2005. I just recently setup CI for our 2005 projects but it's just plain ugly, in so many ways. First there was trying to get the system to build using MSBuild. That was fine because you can simply enter this:

msbuild /t:rebuild solutionname.sln

(or whatever target you want like Debug or Release)

Like I said, if that's all it was no problem but it gets real ugly real fast.

First there's VSTS unit test projects. The team is all equipped with Visual Studio Team Suite. An expensive proposition, but one made long ago by someone wiser than me. No problem though. We're not really using the Test Manager much, there are no automated web tests, so we just write unit tests (and run them with Jamie Cansdales excellent TestDriven.NET). However when MSBuild gets ahold of a solution that contains a VS unit test project it needs some additional set of assemblies (assemblies buried in the GAC_MSIL and other places). The snippet in the ccnet.config file to get MSBuild going was pretty straight forward:

<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>D:\ccnet\projects\ProjectName</workingDirectory>
<projectFile>SolutionName.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<targets>Build</targets>
<timeout>600</timeout>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>

Through brute force (run MSBuild, figure out what assembly it needs, go find it, lather, rinse, repeat) I was able to get a 2005 solution (with unit test projects) to compile. However actually running the tests is another story. Again brute force reigned supreme here as I trodded through an hour or two of running MSTest.exe to try to coax a couple hundred unit tests to run. The cc.config entry for getting some unit tests looks something like this:

<exec>
<executable>C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MSTest.exe</executable>
<baseDirectory>d:\ccnet\projects\ProjectName</baseDirectory>
<buildArgs>/testcontainer:Source\Tests\UnitTests\bin\AutomatedBuild\UnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>

Remember that I said this sever did not have Visual Studio installed. For the VS2005 solutions, I just installed the .NET SDK 2.0 and that was good enough. Although MSTest.exe isn't included, I snagged the file (and it's crazy set of additional DLLs scattered all over the hard drive) from another system and stuck it where the EXE was so it would be happy.

No dice on running MSTest against a unit test project. It started down the path of running the test, but then hit a crazy COM error (CLSID not registered) and that was enough for me. No way I'm going to track down all the stupid COM registry settings for Visual Studio 2005. And what the hell was this? COM? I thought we got rid of that about 3 compilers ago?

So I was stuck to installing a full Team Suite on the server. Okay, I'll bite. I mean, I don't need everything so it'll be okay (I keep telling myself as I watch a million registry entries fill up). A few hours later and I'm staring at my command prompt again and type in my MSTest.exe command. And a dialog box pops up. Yup, a modal dialog box that tells me something is wrong (I don't remember the specifics but it wasn't very informative).

Visual Studio was installed fine and I could compile and run and build the solution I was trying to, but testing from the command line with MSTest.exe was a no-go. No matter how hard I tried, how much I cleaned up, or how many virgins I sacrificed it just won't go. And there's another problem. With 2003 and our NUnit tests, we go some nice stats. Timings, informative messages, all that good stuff. With MSTest we get nothing (other than x number of tests ran and maybe a failure, but I couldn't get that far to see if it would give the details of the failure). On top of that, the MSBuild logger bites and produces about 10,000 lines of gobbly-gook that isn't very useful. Yes, I could spend my time writing new xslt to make it pretty, trim out the "Everything was okay" lines that fill up the MSBuild task logger but I think that's not value-added at my rates.

Here's a sample email I got from the build which gives you an idea of how useless a CC.NET/MSBuild/MSTest combo is:

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有