This post was originally published here
As most know a BizTalk Solution has two major parts – its resources in form of dlls, and its configuration in form of bindings.
In an previous post
I described how to build and pack resources into an MSI using Team Foundation Server (TFS) Build Services. Managing the configuration in a similar way is equally important.
So let’s see how we can build environment specific binding files using TFS Build Services and some config transformations syntax goodness!
Creating a simple binding example for development and test environment
Let’s start with a simple example of a simple binding with a receive port, receive location and a
send port for two different environments – one called “Test” and one “Production”.
| Port type | Name | Destination path in Test | Destination path in Production |
|---|---|---|---|
| Receive Port | BtsSample_ReceivePort_A | N/A | N/A |
| Receive Location | BtsSample_ReceivePort_A_Location (File) | C:TempIn*.xml | C:TempIn*.xml |
| Send Port | BtsSample_SendPort_A (File) | C:TempTESTOut%MessageID%.xml | C:TempPRODOut%MessageID%.xml |
As one can see there’s a small difference between the send ports destinations paths in Test and Production.
Exporting a binding template
Next we’ll create a binding template. The binding template will hold all information that is shared between the different environments.
This is achieved this by an ordinary export of the application binding from the BizTalk Administration Console – as you’ve probably done many times before.
Creating environment specific bindings using web.config Transformation Syntax
The Web.config Transformation Syntax is feature that showed up in Visual Studio 2010 and
is often used to transform app.config and web.config files between different versions and environments – but it will of course work on any type
of configuration file. Including BizTalk binding files!
So for each environment we’ll then create an environment specific config file that only contains the values that differs between the template and
the values for that environment. We use the Web.config Transformation Syntax to match the nodes and values that we like to update in the template.
Below is the Test environment specific file matching the send port and replacing the value with the value specific for Test.
The Production specific file also matches the send port but with a different value for the Destination path.
Using MSBuild to execute the transformation
As part of the Visual Studio installation an MSBuild target is installed for executing the transform.
The target is installed into the standard MSBuild Extensions Path
which usally mean something lilke C:Program Files (x86)MSBuildMicrosoftVisualStudiov10.0WebMicrosoft.Web.Publishing.targets
depending a Visual Studio version etc.
Finally we’ll add a small .proj file to pass some parameters to the MSBuild process. We need to tell the process what file to use as
template and what different environment specific files we like to use.
Next we can kick of MSBuild and point it to the cretated proj file. C:WindowsMicrosoft.NETFrameworkv4.0.30319MSBuild build.proj.
Voila! MSBuild has performed our transformation and created two complete environment specific binding file by combining the template with the specific environment files – one of test and one for production.
Generating the file using TFS Build Services
Start by setting up a TFS build definition as described in previous post on
Generating BizTalk MSI using TFS Build Services.
We then need to add the $(DestinationPath) property to our Destination path to make sure the outputted binding files are written to the same
path as the rest of the resources.
Once we have our build template all that’s needed is to add the build.proj file to the files to compile as shown below.
When finally running the build our two complete binding files are written to the deployment area and ready for installation!