Jenkins and .Net

Jenkins and .Net

butler This week I visited the first JUG’s event in Bern. The topic was Jenkins (fork of Hudson). The presentation of Dr. Simon Wiest was very entertaining. He explained continuous integration and showed how easy it is to install, configure and run Jenkins.

.Net integration in Jenkins

Jenkins is from the Java ecosystem, so it isn’t obvious to use it in a .Net environment. But one of best thing of Jenkins is that there exists a lot of plugins. So, there are also plugins for .Net:

  • MSBuild support
  • NAnt support
  • MSTest support
  • NUnit support
  • NCover support
  • TFS support


First you have to download Jenkins from Then you type on the console:

java -jar jenkins.war

And that was the whole installation. Well, you could now install Jenkins as a windows service, but that isn’t hard too. There exists a command to do that in the “Manage Jenkins” menu.

To use Jenkins in a .Net environment you have to install the needed plugins first. I installed the following plugins through the UI:

  • MSBuild
  • NUnit

After you installed the plugins you have to restart Jenkins and don’t forget to check if you have to configure the installed plugins.

Simple project setup

To show the configuration, I show you the same project “DokuDB” on Jenkins and  on CruiseControl.NET.



The project “DokuDB” is  a .Net 4.0 project with a NUnit Test project. So, the steps of the build servers has to be the following:

  1. Get sources out of the SVN repository
  2. Build the application
  3. Run the unit tests
  4. Examine the results of the unit tests

Sample with Jenkins

You can configure your build of your project through XML or UI. If you haven’t much experiences with Jenkins I recommend the UI way. The resulting XML is the following:

<?xml version='1.0' encoding='UTF-8'?>
  <scm class="hudson.scm.SubversionSCM">
    <browser class="hudson.scm.browsers.WebSVN">
    <workspaceUpdater class="hudson.scm.subversion.UpdateUpdater"/>
  <triggers class="vector">
      <spec>* * * * *</spec>
      <msBuildName>MSBuild 4.0</msBuildName>
      <command>"c:\Program Files (x86)\NUnit 2.5.8\bin\net-2.0\nunit-console.exe" src/Doad/Doad.Test/bin/debug/Doad.Test.dll</command>

Jenkins doesn’t have by default an application for the system tray on the developer machines, so that the developer can observe the build state. But there are two available tray-apps:

Sample with CruiseControl.NET

To configure your build in CruiseControl.NET you have to edit the ccnet.config file. CruiseControl.Net hasn’t an UI to edit the configuration, but there is an application to validate the config file: CCValidator. The resulting config file for the sample project looks like that:

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
		<sourcecontrol type="svn">
			<executable>C:\Program Files (x86)\Subversion\bin\svn.exe</executable>
			<webUrlBuilder type="websvn">
				<logger>C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
			<exec executable="C:\Integration\Doad\src\Doad\packages\NUnit.\Tools\nunit-console.exe" buildArgs="C:\Integration\Doad\src\Doad\Doad.Test\bin\Debug\Doad.Test.dll /xml:doad-results.xml /nologo"/>
			<xmllogger />
			<intervalTrigger name="Continuous integration" seconds="30" initialSeconds="30" />

CruiseControl.Net has an own System Tray application, the CCTray.


Jenkins is really easy and fast to install and configure. In comparison to CruiseControl.NET the Look&Feel is much nicer. 
All downloaded plugins for .Net worked well except the TFS-plugin, but there was maybe a problem with the Team Foundation server.

For the next (ALT.NET)-project I consider to use Jenkins instead of CruiseControl.NET.

Dr. Simon Wiest wrote also a book about Hudson:

8 thoughts on “Jenkins and .Net

  1. Thanks for sharing.

    How do we specify working directory in ccnet.config when two or more developers are working on the same project, as they could have different working directory folder paths, where they check in/commit their code. We are using svn, could you let me know how do I specify the working directory path ?

  2. Hi Kalyan,

    When your developers check in their code from whatever directory they are working in, the commit goes into the repository. CC.Net then uses and SVN checkout to pull the code into its own working directory, where it can build and test and do whatever else you have configured it to do. CC.Net does not know (and does not need to know) how many developers you have, and what directories they were/are working in, it uses its own space.

    I hope this helps,

  3. @Zachary Young
    Hi Zachary

    Thank you for the response for the question of Kalyan.

    @Kalyan: Think of a Continuous Integration server as an additional developer on your team. It has its own directory where it checkout the source out of the SVN repository. The configuration of the Continuous Integration server is independent of the development environments of the other developers (except the path to the SVN).


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.