Get Started With Continuous Integration For Your .NET (C#) Projects - Build Your Project

In this post, I will recall my recent experience on continuous integration using Jenkins and Sonar in a C# project. There isn't much information found in this area especially the resolution to a few tricky issues I encountered. Therefore, I wrote this in English so that it may help non-native Chinese speakers as well.

Why continuous integration?

We all know that early integration is critical to software projects as issues could be found in the early phase.  The earlier to find an issue, the lower the fixing cost is.  Continuous integration makes even further, which encourages integration as frequently as possible so that it is easy to root cause an issue because the scope of the issue is limited to recent a few code checkins.

Background and Goals

The C# project was developed in visual studio 2010.  The solution file has 4 sub-projects in it, 1 project containing the source code, 2 unit test projects, 1 setup project(create the installer). The source code is managed in SVN.

The goals are:

1. Build the project, run unit test for every code code checkin.

2. Run sonar analysis every mid-night, which includes, build the project, run the full-set test cases, run static code analysis and calculate code coverage, post the results to the sonar system.

Let's Get Started!!!

1. Get Jenkins Installed.

This is the most simple one. Just follow the instructions guide on the Jenkins website.  If you install Jenkins on a Windows machine using the installer, Jenkins is installed as a windows service by default (My Jenkins version 1.442). Therefore, you will not see the "Install as Windows Service" menu in the Manage Jenkins page. 

To verify Jenkins is installed correctly or not, visit http://localhost:8080.  Thanks to the Jenkins team to make the installation in such a simple way.

2. Get the Project Built

Now that the Jenkins server is running, let's use Jenkins to build the project. Here are the things we need to do before the project can be built:

• Install the MSBuild plugin for Jenkins.  What the plugin does is to enable Jenkins to invoke the msbuild.exe to build your project.  The plugin can be installed via the Jenkins web management interface (http://<your_jenkins_sever_ip>:8080), Manage Jenkins -> Manage Plugins.  The Jenkins needs to be restarted after the plugin is installed.

• Configure MSBuild: After the MSBuild plugin is installed, you need to configure the path to the msbuild.exe (Manage Jenkins -> Configure System).  Multiple MSbuild can be configured so that different project can be build using different version of MSBuild.
  [Figure 1]
  

Jenkins is nothing but a jobs management system which does the jobs you tell it to do. Before we create a job to build the project, let's take a look at the basic elements of a job.

1. Job name: Each job has name to identify itself in the Jenkins system.
2. Trigger: it defines when the job should be started.  There are several triggers provided by Jenkins.  For the sake of simplicity, we don't configure any trigger for now.  We will start it manually at this point.
3. Source Code Management: Jenkins needs to checkout source code from the source code management system (SVN for me)  to build the project.  Jenkins has built-in support for SVN, so this saves me some efforts.
4. Build Steps: This is what you tell Jenkins to do. Build steps could be running windows batch commands, running shell scripts or running ant, and so on. MSBuild plugin installed earlier adds one step here for you to build .Net projects using msbuild.exe.
5. Post Build Tasks: once all the build steps complete, there are quite a lot post build tasks you could choose.  We don't need it for now.
   

At this point, we only need #1, #3 and #4 to get the job running.  Here are the steps to create a job to build the project:

1. Click the New Job on the top left corner.  In the opening dialog, choose "Build a free-style software project", give a name to the job and click OK to configure the new job.
2. Specify the source code: in the source code management section, specify the source code location (repository URL). Jenkins has built-in support for CVS and SVN. Other plugins need to be installed to support ClearCase, Git or other source code management tools.
   [Figure 2]
   
   
3. Add a build step: Click the "Add build step" button in the Build section, and choose "Build a visual studio project or solution using MSBuild".  Note that, more steps can be added here.  By default, the steps are running sequentially.  If you want a step to run conditionally, you could install the Conditional Step plugin.
   
   
4. Specify the parameters for the msbuild:
   
   1. At the newly created build step, select the msbuild version we created earlier.  If your projects need different msbuild versions to build, create more msbuild version in the Configure System under Manage Jenkins.
      
   2. Specify the solution file to be built.
   3. Specify the parameter needed for your build. In general, specifying the configuration and target is enough.  You may refer to the msbuild manual for more detailed parameters.
      
      

Save the configuration and click the Build Now on the left. If everything works well, your solution will be built in Jenkins.

3. Hold On.  Build Failed. - Trouble Shooting Tips

If anything can go wrong, it will.  The build may fail at the first attempt.  Here are the trouble shooting tips that may help you.

1. Do a "unit test" for your solution file. You may consider build the solution manually using the msbuild from the command prompt before build it using Jenkins.  This is to make sure the solution settings are correct.  If your solution can be built successfully using the msbuild.exe from command prompt, then the error is related to the integration with Jenkins.
   
2. Check out the "Console Output" which is accessible on the left menu of the build.  In the console output, you could find the error message when the error occurs.
   
3. Check out the msbuild path is correct.
4. Jenkins will checkout a copy of the source to the job workspace, which is under <jenkins_installation_root>\jobs\<job_name>\workspace. Check if all the required source code are in the workspace.
5. Check if the solution file path is correct or not.  The Jenkins job working directory is the workspace, so the solution file path should be based on the working directory.

Hope you have solved the issue.

4. Hold on, MSBuild cannot build vdproj

If you have a *.vdproj project to create windows installer for your project.  The msbuild does not support build a vdproj project.  There are a few options, 1) switch to WIX (i didn't get a chance to study it; 2) use the devenv.com to build vdproj which is what I did.

A few things to note:

• Use devenv.com (or devenv) to build it, not devenv.exe. devenv.exe invokes the devenv.com to build the project in the background, and the devenv.exe will exit. Jenkins will not be able to track the build progress.
  
• You need to install a visual studio hotfix before it can build the vdproj.  For visual studio 2010, the hotfix can be downloaded at:http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30681
• You need to add another windows batch command step to build the vdproj project.

Hope you are doing well.  At this point, your C# project should be able to build in Jenkins manually.  We will see how to make it build automatically.

5. Build the project automatically - using trigger

Since we are talking about continuous integration, the project should be build as soon as the code is checked in.  Jenkins is able to poll the SCM to find out if there are newly code changes. If there are new code checkin, it could trigger a new build.

In the Trigger section of configuring your job page, choose Poll SCM, and it allows you to configure how often Jenkins polls the SCM for changes.  You could configure it to check SCM changes every a few minutes.  Below is my configuration, it polls SCM every 5 minutes from Monday to Friday.

# Poll SCM every 5 minutes from Monday to Friday*/5 * * * 1-5

Since the project is built much more frequently than before, each build should finish in less than 10 minutes according to the continuous integration practice.  Otherwise, it will discourage people to check in.  Reducing the build duration is out of the scope of this post.

6. What's Next?

Now we have met part of our first goal - build the project for every code checkin.  Next we will explore how to run the test cases during the build. Stay tuned.