Jenkins and .Net
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
Installation
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:
- Get sources out of the SVN repository
- Build the application
- Run the unit tests
- 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'?>
<project>
<actions/>
<description></description>
<keepDependencies>false</keepDependencies>
<properties/>
<scm class="hudson.scm.SubversionSCM">
<locations>
<hudson.scm.SubversionSCM_-ModuleLocation>
<remote>svn://<svn-server>/<svn-repo>/trunk</remote>
<local>.</local>
</hudson.scm.SubversionSCM_-ModuleLocation>
</locations>
<browser class="hudson.scm.browsers.WebSVN">
<url>http://<WebSVN-server>/listing.php/?repname=<svn-repo></url>
</browser>
<excludedRegions></excludedRegions>
<includedRegions></includedRegions>
<excludedUsers></excludedUsers>
<excludedRevprop></excludedRevprop>
<excludedCommitMessages></excludedCommitMessages>
<workspaceUpdater class="hudson.scm.subversion.UpdateUpdater"/>
</scm>
<canRoam>true</canRoam>
<disabled>false</disabled>
<blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
<blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
<triggers class="vector">
<hudson.triggers.SCMTrigger>
<spec>* * * * *</spec>
</hudson.triggers.SCMTrigger>
</triggers>
<concurrentBuild>false</concurrentBuild>
<builders>
<hudson.plugins.msbuild.MsBuildBuilder>
<msBuildName>MSBuild 4.0</msBuildName>
<msBuildFile>src/Doad/Doad.sln</msBuildFile>
<cmdLineArgs>/t:Clean;Rebuild</cmdLineArgs>
</hudson.plugins.msbuild.MsBuildBuilder>
<hudson.tasks.BatchFile>
<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>
</hudson.tasks.BatchFile>
</builders>
<publishers>
<hudson.plugins.nunit.NUnitPublisher>
<testResultsPattern>*.xml</testResultsPattern>
<debug>false</debug>
<keepJUnitReports>false</keepJUnitReports>
<skipJUnitArchiver>false</skipJUnitArchiver>
</hudson.plugins.nunit.NUnitPublisher>
</publishers>
<buildWrappers/>
</project>
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">
<project>
<name>DokuDB</name>
<sourcecontrol type="svn">
<executable>C:\Program Files (x86)\Subversion\bin\svn.exe</executable>
<trunkUrl>svn://<svn-server>/<svn-repo>/trunk</trunkUrl>
<workingDirectory>c:\Integration\DokuDB</workingDirectory>
<webUrlBuilder type="websvn">
<url>http://<WebSVN-server>/diff.php?repname=<svn-repo>&path={0}&rev={1}&ignorews=1</url>
</webUrlBuilder>
</sourcecontrol>
<tasks>
<msbuild>
<executable>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe</executable>
<workingDirectory>C:\Integration\Doad\src\Doad</workingDirectory>
<projectFile>Doad.sln</projectFile>
<targets>Clean;Rebuild</targets>
<logger>C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<exec executable="C:\Integration\Doad\src\Doad\packages\NUnit.2.5.7.10213\Tools\nunit-console.exe" buildArgs="C:\Integration\Doad\src\Doad\Doad.Test\bin\Debug\Doad.Test.dll /xml:doad-results.xml /nologo"/>
</tasks>
<publishers>
<merge>
<files>
<file>doad-results.xml</file>
</files>
</merge>
<xmllogger />
</publishers>
<triggers>
<intervalTrigger name="Continuous integration" seconds="30" initialSeconds="30" />
</triggers>
</project>
</cruisecontrol>
CruiseControl.Net has an own System Tray application, the CCTray.
Conclusion
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”
thanks!!! for sharing the code
good work
…..
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 ?
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,
Zachary
@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).
Patrick