March 2009 - Posts

BizTalk Server 2009 - automated build & deployment using TFS 2008 – parameterization
23 March 09 10:39 PM | Johan Hedberg

This post is all about how you can parameterize your builds to work in different scenarios. Before you read this, please take a moment to read Mikaels introductory blog post and take a look at my webcast on Channel9 [~18m], if you haven't already - it will eaze your understanding of this article.

To put this post in to context, let’s assume we have a multi target environment, with multiple servers in the production environment.


So for this sample we have two environments; Test and Production. The Test environment has one server (TEST1) whereas the Production has two (PROD1 & PROD2).

Scenario 1 – Deploying to Test for the first time

As the developers are done and have checked in their code and binding files, they are ready to create a Build Type. They do this through the Team Explorer add-in, after which they’ll make a small modification to the build script (as described in the Mikaels introductory post).  After this – all they have to do is to “Queue New Build” and choose the Build Agent running on the TEST1 machine. No parameters required.


The solution will then be Compiled, Added to GAC and Deployed to BizTalk. The last step would be to Import the bindings files to create the ports etc.

Scenario 2 – Deploying to Test for the second time

If the structure of the solution has not changed since the last build, – the developer would just Build the solution as described in Scenario 1, where it is first being Undeployed and Removed from the GAC before it’s being redeployed.

However, if the structure of the solution has changed, there might be an issue. For example, let’s say the developer originally had two projects, one “orchestration project” and a “schema project” (referenced by the first one), and then decided to do some refactoring to consolidate the two projects into one. Deploying this updated solution will cause an conflict since the “schema assembly” is no longer part of the bindings file, and will therefore not be removed.

This can be resolved by undeploying the previous label or changeset using the following parameters:

/P:GetVersion=C1234;Deploy=false (using changeset)

/P:GetVersion=LTimeReporting_20090310.1;Deploy=false (using label)


When the solution is undeployed, the developer can building the solution again. This time, without any parameters. Just like we did in scenario 1.

Scenario 3 – Deploying to Production

Same configuration described in Scenario 1 and 2 applies to building to the Production environment. Although there is no need to create additional Build Types, you would however need to select a different Build Agent - the one running on the PROD1 machine instead of the one on TEST1.

However, the scenario is a bit different since you also need to add the assemblies to the GAC on the PROD2 machine. To accomplish this you could just run the build agent on both machines and thus run the full build/undeploy/deploy sequence on both machines. That's however a undesirable scenario. Originally we did this using another form or parameterization where we would use a gac_only flag on PROD2. However Mikael recently made an update to use PsExec after at tip from Kent Weare about how to use PsExec to remotely copy and install assemblies to the GAC. This enables you to run the build only on one machine. All that is needed is to make some modifications to the Build script (TFSBuild.proj). Alternatively, if all solutions are deployed to the same environments, you could do this change to the Blogical.BizTalk.CustomTasks.targets file located in the TeamBuildTypes folder (again; see webcast or read Mikaels introductory blog post).

Download version 1.1 of the Blogical.Shared.Tools.BizTalkBuildTasks (latest at the time of writing).


The Zip file includes the Custom Tasks library and the file.

  1. Save the Blogical.Shared.Tools.BizTalkBuildTasks.dll file to preferred directory on each server running the Build Agent. You can use a network share.
  2. Edit the Blogical.BizTalk.CustomTasks.targets file (line 40). Set the <Blogical_CustomTasks> to the directory where you saved the Blogical.Shared.Tools.BizTalkBuildTasks.dll.
  3. Check in the Blogical.BizTalk.CustomTasks.targets file to the TeamBuildTypes folder in you TFS project.
  4. Download and install PsExec. You need to complete this step on each of the servers running the build agent.
  5. Edit the Blogical.BizTalk.CustomTasks.targets file (line 43). Set the <PsExecPath> to the path where you installed PsExec.


Filed under: ,
14 March 09 09:33 PM | Johan Hedberg

Since all the cool kids are hanging out at Twitter, I am too. I'm slightly late to join the party, but at least I made it.

With the upcomming TechDays I meaned to keep it updated with my experiences during the conference, however my Xperia X1 smartphone has become broken just in time, and my loaner is a 3 year old sonyericsson with no internet capabilities, so we'll see how that goes. My alias is JoHed.

Although you should expect my Twitter space to update much more often then this blog, We're also just starting up two new BizTalk projects, as well as doing some really interesting internal work, so I'm sure I'll continue to have lots to write about here as well.

Another announcement worthy of being mentioned in the blog as well as on Twitter is that not only did I recently pass my WCF exam (70-503), I also did so in time before begining to teach the WCF course I had scheduled to start this week. It's a multi-week engagement taking place in the evenings, with the goal being that people will have a try at the certification, so we'll see how that works out. I have high hopes.

This Blog



    Twitter Updates

      Follow me on twitter


      Feedburner Subscribers

      Locations of visitors to this page


      All material is provided AS IS voiding any thinkable or unthinkable effect it might have for any use whatsoever. There... is that clear enough ;)