Category: Continuous Integration

Using NUnit for a .Net 4 project in a Jenkins installation

I have migrated my MBUnit tests to NUnit, considering MBUnit has been “on hiatus” for about a year now. NUnit is not much more agile, but at least there is a semblance of life on their Github account.

The switch has been surprisingly easy: change the namespace, change TestRow with Test, and change Row with TestCase. Easy!

Run unit tests in your continuous integration platform

In order to integrate the tests in our continuous integration platform, while minimizing build time, I have split the setup package build and the unit tests run. So I have a job that runs at each commit, that builds the project and generates the setup packages; and another job running at midnight, that only builds the project and runs unit tests.

Apparently, using the automatic package restore from Visual Studio is now obsolete with the latest Nuget versions. So I followed the instructions and migrated to Nuget package restore. Remember to download nuget.exe from nuget.org, add it to the CI server’s PATH, and restart Jenkins.

Add the NUnit Nuget packages to the test projects, and remember to add the NUnit Runner Nuget package to the solution! It will be much easier to run the unit tests this way (no need to install NUnit on the CI server).

I’m using PSAke for my build process (awesome tool!), so now my script looks like this:

And now my Jenkins jobs consist of a simple batch line:

I have sumbled on a System.BadImageFormatException while running tests in Jenkins using nunit-console, or trying to add the assemblies to the NUnit GUI runner. Here are a few things to remember:

Do not use AnyCPU

Your test assemblies, assemblies linked by your tests, and really your whole project, should be built in 32-bits mode, so that they can be run by the 32-bits test runner. Personnaly, I created a “NUnit” solution configuration just for this. It allows me to select which assemblies are built in which case: no need to build tests in the general build, and no need to build stuff like bootstrapper exes in the test build.

Check your build paths

If you create a new configuration like I did, remember to change the build path! My main project builds in the \build\app folder, and my tests are located in \build\tests. I spent a few minutes wondering why the platform change did nothing, before finding out that my x86 test assemblies were in bin\x86\NUnit (the default value).

Check the framework version

Select the proper .Net framework with the /framework:net-4.0 switch. NUnit should be able to find out automagically, but sometimes it doesn’t.

Exploring various .NET build solutions: Albacore vs FAKE vs PSake

As I said in a previous post, I am changing our build process for our application, so I’m testing several build solutions.

FAKE is the newest and shiniest tool for .Net users. F# looks like a cross between Ruby (for the general syntax), and PowerShell (for the piping-fever-dream). Unfortunately, it seems to be missing a core piece of any proper build system: running an arbitrary exe file. I need to run the setup builder (InnoScript), but all I can find is creating a custom task, and it’s way overkill, and not very evolutive. Documentation is incredibly hard to find because of its generic name. Pro tip: do not name your software after a random generic word.

Albacore is great, running on Ruby, using Rake tasks. Installing Ruby on Windows is easy, as long as you don’t try to use some gems that won’t compile on your system. Unfortunately, Jenkins installed on Windows won’t run the ruby installed with Ruby Installer, for various reasons: PATH problems, rights problems, etc. Too bad, because my build script was working great.

PSake might be the easiest to use on a Windows build system. Documentation for PSake itself is very light, but Powershell is very well documented, very powerful, and we already use it in various places in our systems, so we know it pretty well.
The only thing I don’t like with Powershell is that, to keep things simple on one side, you have to do complicated things on the other. I don’t want to install a thousand plugins in Jenkins, so I need to build a batch “boostraper” that runs the PS scripts.

The good thing is that PSAke and Rake are very similar, so I was able to write the equivalent script in a few hours, just by putting my Rakefile and build.ps1 files side-by-side in Sublime Text.

Update

After a year working with PSake for all of my build scripts, I can confirm that it’s awesome. Powershell is a great automation language, it’s very mature, and it has thousands of libraries and extensions.

Building a .NET application for distribution

We have a Windows (WPF) app distributed to end users (general public).

I am changing the build process to simplify it. It is currently comprised of these steps :

  1. A SVN commit runs a Jenkins build
  2. Jenkins runs a few NAnt scripts
  3. NAnt builds the application through MSBuild
  4. It then launches a custom application that does several things:
    1. It downloads a few infos through a webservice, updates a DB, etc
    2. It modifies InnoSetup scripts with a few dynamic informations, like the version number
    3. It signs the binaries with a SSL certificate
    4. It launches the InnoSetup scripts to create the setup packages
    5. It signs the setup packages with the SSL certificate
  5. It then changes a few things before running the custom app again, in order to generate a different setup package

That’s quite a complicated and convoluted solution to a not-so-complicated problem. And, most importantly, it uses too much different technologies : I believe both the NAnt scripts and the custom application can be removed from the process.

So, I’m looking for a suitable replacement. I’ve had my eyes on Albacore for a few weeks, which looks very fun, and would allow me to use Ruby, which I might need to learn for later projects. But it has important problems:

  • It’s very light on documentation: the official wiki documents the V1, but it’s incompatible with the current V2, which is better. You have to look at the sources to see what’s available to you, and how to use it.
  • Help is hard to come by on the net.
  • It uses Ruby
    • it’s yet another layer in the build stack
    • it won’t allow me to get rid of the custom app (good luck updating an Access DB through a SOAP webservice)
    • runnig Ruby on Windows is easy, but many gems are not available (some of them very useful)

So now I’m looking at FAKE, which also looks promising. It has the huge advantage of allowing me to easily migrate the custom app (or simply reuse its components), because it’s .NET. But it also has problems:

  • Documentation does not seem much better, even though I haven’t yet started using it, so maybe it’s enough
  • Help seems to be even harder to come by, there seems to be even less FAKE questions on Stackoverflow than Albacore
  • It uses F#, which I don’t know at all, and won’t need in the future, but it’s always interesting to learn a new language (and apparently it’s the new kid on the block in .NET)

That being said, I will try FAKE anyway. It will allow me to remove build layers, and maybe remove the custom app. It will also probably be more easily adopted by the .NET community, especially since Scott Hanselman posted about it a few weeks ago.

Looking from the comments there, if FAKE does not work for me, I might want to try PSake: it’s in PowerShell, wich is a great scripting language, and I know pretty well already.