Home > .NET, First experiencies, New technology > Jenkins and .Net

Jenkins and .Net

February 24th, 2011 Leave a comment Go to comments

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 http://jenkins-ci.org. 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:

If you like this, follow me on twitter…

Categories: .NET, First experiencies, New technology Tags:
  1. February 25th, 2011 at 06:25 | #1

    thanks!!! for sharing the code
    good work

  2. Kalyan
    July 22nd, 2011 at 13:51 | #2

    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 ?

  3. August 11th, 2011 at 00:10 | #3

    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,

  4. August 11th, 2011 at 10:38 | #4

    @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).


  1. February 25th, 2011 at 03:49 | #1
  2. May 12th, 2011 at 22:00 | #2
  3. October 29th, 2012 at 06:30 | #3
  4. July 23rd, 2013 at 14:27 | #4