Blog.

CI with Jenkins, MSBuild, Nuget and Git part 1

MF

Marco Franssen /

4 min read624 words

Cover Image for CI with Jenkins, MSBuild, Nuget and Git part 1

Very lately I have worked on setting up some continuous integration (CI) using MSbuild for my c# project. In this blog series I will explain to you how to set up continuous integration.

First of all we will start with creating a MSBuild script which will compile our code. We will also create a small batch file for easy executing the MSbuild script.

When that is in place, we will add several targets to the build script to run for example unit tests, integration tests, code coverage, packaging etc.

So we will take the agile approach and improve our build process based on validated learning.

First of all we need some basic knowledge about MSbuild. I think there are enough pages around on the web which will give you a basic introduction. A good starting point would be the MSDN documentation for MSBuild.

Let's consider we have the following project structure within our Git repository / local file system.

src (contains our source code)
|- lib (contains build output, and third party libs not available on nuget)
|- reports (contains code coverage reports, test scenarios and test results)
|- ci.msbuild (your msbuildfile)
`- ci.msbuild.cmd (your batch file to execute the build on your local machine)

ci.msbuild

In this first version of our build file we only have one target (Compile). This target will build our projects. We do not use the solution file because someone can disable items from the build in the  solution configuration. By using the projects explicitly we are sure all necessary projects will be build. We also have a PropertyGroup to define some variables.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
         DefaultTargets="Compile">
  <PropertyGroup>
    <Configuration>Debug</Configuration>
    <Platform>AnyCPU</Platform>
    <DefineSolutionProperties>false</DefineSolutionProperties>

    <!-- General Paths -->
    <RootPath>$(MSBuildProjectDirectory)</RootPath>
    <SrcPath>$(RootPath)\src</SrcPath>
    <ReportsPath>$(RootPath)\reports</ReportsPath>
    <ToolsPath>$(RootPath)\tools</ToolsPath>
    <Packages>$(SrcPath)\packages</Packages>
  </PropertyGroup>

  <Target Name="Compile">
    <Message Importance="high" Text="Compiling projects"/>
    <MSBuild Projects="$(SrcPath)\MyProject.Core\MyProject.Core.csproj"
             Properties="Configuration=$(Configuration);Platform=$(Platform)" />
    <MSBuild Projects="$(SrcPath)\MyProject.Web\MyProject.Web.csproj;$(SrcPath)\MyProject.Win\MyProject.Win.csproj"
             Properties="Configuration=$(Configuration);Platform=$(Platform)"
             BuildInParallel="true" />
  </Target>
</Project>

ci.msbuild.cmd

Using following batch file we can easy execute the build script and providing a Configuration for the build.

@echo off

setlocal
set msbuild="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe"

set /p configChoice=Choose your build configuration (Debug = d, Release = r? (d, r)

if /i "%configChoice:~,1%" EQU "D" set config=Debug
if /i "%configChoice:~,1%" EQU "R" set config=Release

%msbuild% _ci.msbuild /nologo /m /v:m /t:Compile /p:Configuration=%config%

pause
endlocal

As you can see we use msbuild.exe and passing our ci.msbuild file as an argument. The /nologo parameter removes some msbuild header texts from the console output. The /m parameter enables parallel build based on the processors available in your machine. The /v:m parameter sets the verbosity to minimal so not everything gets outputted to the console. The /t:Compile parameter tells msbuild.exe to execute the Compile target from our build file and the /p:Configuration=%config% parameter injects our build configuration (Debug/Release) into the build.

When we would skip the /p parameter the default Configuration will be Debug as defined in the PropertyGroup of our build script. When we skip the /t parameter the default target Compile will be executed as defined in our msbuild file.

So for now you are able to build your projects using a simple batch file. In the next part of this blog I will describe adding a LoadNuGetPackages target which will download all the Nuget packages based on your package configs. At least most of us are using Nuget today. We will also be adding a Clean target which will clean our directories before we will compile again, so we won't get stuck with possible old assemblies from earlier compiles. Please share this article with your friends and please be curious for the next part of this series :D.

You have disabled cookies. To leave me a comment please allow cookies at functionality level.

More Stories

Cover Image for CI with Jenkins, MSBuild, Nuget and Git part 3

CI with Jenkins, MSBuild, Nuget and Git part 3

MF

Marco Franssen /

In the previous parts (part 1, part 2) of this series I described how to clean, download Nuget packages and build your solution using MSBuild. In this part I will explain you how to create a MSpec MSBuild target and a Code coverage MSBuild target. MSpec is a testing framework which enables you to write living specifications. Using the MSpec console runner you can easily generate an html report. This report can later on be published using the Jenkins report plugin. By publishing this report we h…

Cover Image for CI with Jenkins, MSBuild, Nuget and Git part 2

CI with Jenkins, MSBuild, Nuget and Git part 2

MF

Marco Franssen /

In part 1 of this blog series we had a look at a very basic MSBuild script which enables us to compile our projects. For doing this I provided you guys with a simple batch file to make it even more simple to execute the build script. In this episode we will focus on cleaning the folders before building again and getting the Nuget packages using Nuget package restore. The latter I will explain further for you first. Nuget package restore can be enabled in Visual studio. A best practice is to en…

Cover Image for Recap my online year 2012

Recap my online year 2012

MF

Marco Franssen /

The year 2012 was for me a year that went way to fast. In the year 2012 I learned a lot new stuff, wrote several blog posts and read lots of blog posts and articles. First of all I want you to give a list of all blog posts I wrote this year. You can find the complete list here http://marcofranssen.nl/2012/ and here http://marcofranssen.nl/2012/page/2/. JavaScript http://marcofranssen.nl/writing-modular-javascript-without-polluting-the-global-namespace/ http://marcofranssen.nl/knockout-js-mapp…

Cover Image for Knockout JS mappings

Knockout JS mappings

MF

Marco Franssen /

Knockout JS is a JavaScript library for creating MVVM JavaScript libraries. In a previous post I already showed some of the cool features of Knockout. http://marcofranssen.nl/knockout-that-cascading-dropdown/ If you want to spike your knowledge on Knockout a little more first, please visit Knockout's documentation. In this article I want to zoom in on the Knockout mapping plugin. The Knockout mapping plugin enables you to easy map your JSON object into an observable JavaScript object. So here…