CI: Hudson with .Net vs CruiseControl.Net [closed]

Answer 1

I cant think of a single thing that Hudson hasnt been able to do for our C# development, even with MSTest based tests, you can now run and trendgraph on them with the new plugin (only works if you are testing ONE assembly) or my method which works on multiple assemblies.

I suppose the only thing that would be nice, would be to generate code coverage data and report on that, not sure if CC.net does that.

Also, Hudson seems to have much stronger community support. I've never heard of someone picking CC.net over Hudson if they had the choice.

We use it to

• Deploy windows services
• Deploy web services
• Run MSTests & display as much information as any junit tests
• Keep track of low,med,high tasks
• trendgraph warnings and errors

These things may not be anything new to Hudson, but I felt the need to re emphasize that Hudson can handle this with a .net project, no problem.

Here are some of the built in .net stuff that Hudson supports

• MSBuild
• NAnt
• MSTest (two methods, linked above)
• Nunit
• Team Foundation Server
• fxcop
• stylecop
• compiler warnings
• code tasks

Also, god forbid you are using visual source safe, it supports that as well. I'd recommend you take a look at Redsolo's article on building .net projects using Hudson

Answer 2

I know almost nothing about Hudson. I will say that since CC.NET is based on .NET, it tends to have lots of built-in and community-contributed tasks and reports relating to the .NET ecosystem:

MSBuild Visual Studio NCover NUnit FxCop etc. etc. etc.

So, if you use these tools, you should carefully check how well they are supported "out-of-the-box" by Hudson. Also, if you end up having to write custom plugins (I have done a few for CCNET), it is usually advantageous to be able to use the development language and IDE that you use for "normal" development.

Answer 3

I cannot fathom why a .Net developer would use a Java CI tool. CruiseControl is a Java-centric tool a well. This is why CruiseControl.NET was created. .NET centric continuous-integration.

If you want to setup a tightly integrated system you will be writing your own plug-ins for the system to make it do exactly what you want.

e.g. Pull together all the version information you care about and then write out AssemblyInfo.cs files with the versions in them.

Answer 4

Hudson is much easier for beginners. We use it to auto-build and pack C++ Builder dlls and exes. Think about that! It's not Java nor C#.

Answer 5

I've checked the hudson support for xunit testing frameworks a short summary is included below:

• MBUnit/Gallio: There is a plugin but the development doesn't seems to be too active nor the community that use it. For example there is only one issue added. It was reported in reported in April and isn't touched yet (August). (Gallio team supports the plugin for CC.Net, their response time looks much better)
• MSTest: Has the same problem. Has only two issues in the issue tracking system and an average response delay is 6 months. (It looks like CC.Net has native support for mstest but requires some configuration)
• nUnit: The support for nunit in hudson seems to be quite good. The dev team is much more responsive and it also has more bugs reported (8 currently).

So I think I'm going to give the CC.Net a try.