Using a build server and leveraging continuous integration is good practice in any software
development project. The idea behind automated build and continuous integrations is to have a server that
monitors one’s source code repository and builds the solution as changes occur. This separate build
activity alone will ensure that all artifacts are checked in and that a successful build doesn’t depend on any artifacts or settings on the development machines.
Today build servers do a lot more as part of the build – the build process usually involves execution of
tests, labeling the source as well as packing the solution into a deployable artifact.
In this post we’ll see how a build process can be achieved using Team Foundation (TFS) Build Services, building a BizTalk project that results in
a deployable MSI artifact.
TFS Build Services
TFS Build services is a component that is part of the standard TFS install media.
Each TFS build controller controls a number of “Build Agents” that will perform the actual build process. For each solution to build one has to
define its process. These processes are described in a “Build Template” that tells the agent what steps to go through
and in what order.
“Build Templates” in TFS Build Services are defined using Visual Studio. The image below shows a build template accessed through Visual Studio Team Explorer.
Major steps in a build template
As one creates a new build template for a solution one has to go through the following major steps:
1. Define a trigger
Decides what should trigger the build. Should it be triggered manually, should it be a scheduled build or should it
be triggered at a check-in of new code?
2. Source Setting
This will tell the build process what part of the source tree the build template is relevant for. When queueing
a new build this is the part of the source tree that will be downloaded to the staging area. It also tells the build
services where on disk the source should be downloaded to.
This is where all the steps and activities that the build service should perform are defined. Team Foundation Build
Services comes with a number of standard templates and custom ones can be added. In this post we’ll however stick with the default one.
Build your first BizTalk solution
Building BizTalk Server solution using TFS Build Services is straight forward.
In this post I will use this sample BizTalk solution. After checking it into Team
Foundation Source Control (I’ll use TFS Source control in this post but it’ll work similarly using Git) I’ll create a new build template for the solution. All that’s
needed to change is the MsBuild platform setting property, so we’re using x86 when executing MsBuild as shown below.
After queuing a build we can in the TFS Build Explorer see a successful build!
We can also download the output from the build where we can see all our build artifacts!
Using BtsMsiTask to create a MSI as part of the build
So far so good, but we started the article by saying that what we wanted was a deployable artifact. In the case of
BizTalk this means a BizTalk MSI. Let’s see what we need to change to also have the build process create a MSI.
1. Install BtsMsiTask
Download and install BtsMsiTask. This will install a MsBuild task for generating the MSI.
2. Add a MsBuild project file
Add a MsBuild project file (
build.proj) to the solution
The project file will tell the BtsMsiTask process what artifacts to include.
Add the created project file to the solution and check it in as part of the solution.
3. Add the MsBuild project file to the TFS build template
Add the created MsBuild project file to the TFS build template by adding it to the list of projects to build.
After another successful build we can see that we also created a MSI as part of the build!
Adding build information to the MSI
As we can see the MSI we just created ended up with the default BtsMsiFile name that is a combination of the BizTalk application name property and the
current date and time. Wouldn’t it be nice of we instead could the build number as part of the name?
BtsMsiTask has an optional property called
FileName that we for
example can set to
When installing the artifact to BizTalk Server we can see that the source location property in the BizTalk Administration Console is set to
where the artifact was built on the staging area.
It’d be nice to also have information about what build that produced these artifacts. This will give the required information to know exactly what builds that are used for all the installed artifacts.
We can change what is set in the source location by using the
SourceLocation property of BtsMsiTask
So after setting the property as below, queue another build, reinstall using the MSI and we’ll get the following result with the build number in the source location property.
And finally this is the MsBuild project file we ended up with in our example.