BizTalk 2009 - Build & Deploy automation with Team Foundation Server 2008 – Part 1

Listen with webReader
Published 11 February 09 01:40 AM | wmmihaa

BizTalk Server 2009 comes with support for MSBuild. The question is, how can we use it, and how does it help us? The obvious advantage is of course, that this enables Visual Studio BizTalk projects to be deployed to the production environment without the pain of exporting/importing MSI packages. This is particular troublesome when dealing with large BizTalk implementations, with lots of assemblies, where you need to select and deselect assemblies to be included in the package.

I have previously posted two articles about using Team Build with BizTalk 2006 (that can be found here and here). That solution where more complex, and had many constraints. This solution is very easy to implement, and only require you to add one (1) single row in you default TFSBuild.proj file.

It is possible to automate deployment using BizTalk Server 2006 R*, but not without installing Visual Studio on the production environment. This is because MSBuild can’t build BizTalk 2006 projects, and you need to use DevEnv to do the work. But since BizTalk 2009 projects are C# project, and C# projects is nothing less then MSBuild scripts, BizTalk 2009 projects can be built on environments without the need of Visual Studio.

But there is  a catch… –It can build, but there is no support for deployment :(

To manage Deployment, we need to do some customization.












When you create a new Build Type in Team Explorer and execute the build, the default build will execute a set of Build Tasks such as GetSources, Compile, Execute Tests etc. The result of the build will give you a folder with the output of the Build. That is a folder with a bunch of assemblies. To deploy these assemblies, we need to figure out where they should deployed to. The obvious place to find this information would be in the bindings files.

So to make use of the new MSBuild support, we need to create three custom tasks:

  • Undeploy Bindings - Since we are going to redeploy the solution, we need to remove all previous assemblies and artifacts.
  • Deploy Assemblies - This Task can optionally be disabled, in case you just want to undeploy. The bindings files will tell us to which BizTalk Application an assembly should get deployed to. if your build results in assemblies that should not get deployed to BizTalk, then these won’t get deployed since they are not included in the bindings files.
  • Import Bindings - This is the last custom task to be executed, and will create all the port bindings. Similar to the Deploy Assembly task, this one is optional is case you just want to undeploy.

Next we need to include these tasks in our build. We do this by adding a single row to our already created Build Type:

<Project DefaultTargets="DesktopBuild" xmlns="" ToolsVersion="3.5">

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
  <Import Project="$(SolutionRoot)/TeamBuildTypes/Blogical.BizTalk.CustomTasks.targets"/>

The Blogical.BizTalk.CustomTasks.targets file includes all necessary targets, and will execute the Undeploy-, Deploy- and Import Bindings tasks after the Compilation Task has been successfully executed.

That’s it!


There are some architectural constraints and considerations you need to be aware of:

Isolated Solutions

The Visual Studio solution is central in this process, and it’s important that projects within this solution should not be part of, or referenced from within any other solution that is going to be used in any Build Type. The reason for this is that the solution might not be possible to undeploy if it’s referenced by any other assemblies.

Bindingsfile location

In order for the Custom Tasks to find the Bindings files, the Bindings files need to be checked in to a folder named Bindings which needs to be located in the same folder as the Visual Studio solution file. Also the Bindings files need to be named [Some Name].[Target Environment].xml. Where the Target Environment could be something like TEST, STAGE, PRODUCTION etc. Eg Navision.OrderConfirmation.STAGE.xml

Shared Components

Global artifacts, such as generic schemas and pipelines, needs to be handled separately from this Build Process, as these are referenced by any number of assemblies, ports and filters.

BizTalk Applications

This Build Process does not create BizTalk Applications. Nor does it manage its references. Therefore you need to create them manually before deploying. As Applications are normally not created on a daily basis, this should not be a big issue.

Utilizing undocumented BizTalk assemblies

The Custom Tasks does not use BtsTask.exe, as it’s difficult to handle exceptions using for example Process.Start. Instead it uses Microsoft.BizTalk.ApplicationDeployment.Engine (also used by BTSTask, ExplorerOM and Visual Studio). This is working very well, but this is not a documented library. I would really like to see Microsoft ship BizTalk with a better supported Deployment API similar to ExplorerOM.


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 44). 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.




# Zeeshan said on February 12, 2009 02:37 AM:

This is top work Mikael!

# New video on using Team Foundation Server for BizTalk Server 2009 development with « Connected Thoughts - Thiago Almeida said on February 13, 2009 05:50 AM:

Pingback from  New video on using Team Foundation Server for BizTalk Server 2009 development with &laquo; Connected Thoughts - Thiago Almeida

# Rojal said on February 17, 2009 09:52 PM:

Nice article. Being a newbie in this field I am trying to confirm if you have to install BizTalk 2009 on TFS Build server for the builds to work?

# wmmihaa said on February 17, 2009 11:03 PM:


You would need to install the Deployment support from the BizTalk installation. However, I don't know if is a need for a "Build server", since you can build to your target environment.

# Rojal said on February 20, 2009 03:09 AM:


Thank you very much. The build itself is working on TFS Build server. I am looking into using your deploy peices now. Do you happen to know any literature that would point me to building a msi that that could be installed in a production environment for example?

# wmmihaa said on February 21, 2009 10:11 PM:

I have a sample for BizTalk 2006, where we had to create msi  packages for installation in production environments.

However, that sample requires the build to be deployed first ( to a build env ), and then extported to an msi package.

If you are working with 2009 Beta, there is no reason to work with MSI files, since you can build on the accual test- or production environment.

Send me a mail (from the blog), if you want the code. If you're working with -06, then you might find these posts of interest:



# info said on February 26, 2009 10:20 PM:

Stort tack till Informator som stod som värdar vid senaste träffen om BizTalk Server 2009 Beta. För dem

# Be Logical - writings by Johan Hedberg said on February 26, 2009 10:29 PM:

I haven&#39;t blogged about it, though Mikael has mentioned it , but in conjunction with the BizTalk

# Simonn said on March 22, 2009 05:58 AM:

I truly appreciate you taking the time to share this . Look forward to more posts from you

# Be Logical - writings by Johan Hedberg said on March 23, 2009 11:44 PM:

This post is all about how you can parameterize your builds to work in different scenarios. Before you

# currency trading said on May 22, 2009 09:36 AM:

Interesting points! I was actually thinking about this topic last night and this morning (particularly how to incorporate it into my own blog). Thanks for the tips, bro!

# Mikael Håkanssons Blog said on June 14, 2009 09:18 PM:

The absence of guidelines and discussions on this topic puzzles me. As I’ve asked myself this question

# eliassal said on July 11, 2009 08:54 AM:

By "Isolated Solutions", shpuld we understand that 2 persons can not work on the same project. What would be the case for a complex system where we might need several developers work on the same solution, every one assigned part of the system

# wmmihaa said on July 11, 2009 11:08 AM:

Any number of developers could work on the same "isolated" solution, but it would require some disipline when it comes to deployment of course. Everyone has to check in there code etc...

# ElenaLisvato said on August 4, 2009 07:26 PM:

There is obviously a lot to know about this.  I think you made some good points in Features also.

# Vineet said on October 25, 2009 07:45 PM:


I am curious to know, if this deployment process takes care of applications where schemas are exposed as services.

I am thinking we will have to manually go through the wizard, or can that be automated.

Also, in scenerios where we have to expose services, wouldn't it be better to export MSI and Binding AND deploy them on individual environment , at least for the 1st time and so far schema exposed as service, is not changing we can continue with automated deployment of modified assemblies.

Please advice



# Andy said on April 23, 2010 11:07 PM:


Great work!! But i just ran into an issue. TFS Service is not able to add assemblies to Gac. Deploy feature is failing. We are building and gacing on a win2k8 r2 server. Tfs Service is part of the admin group on the machine.

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED.

at Microsoft.BizTalk.Gac.Fusion.IAssemblyCache.InstallAssembly(AssemblyCacheInstallFlag flags, String manifestFilePath, FusionInstallReference referenceData)

  at Microsoft.BizTalk.Gac.Gac.InstallAssembly(String assemblyPathname, Boolean force)

  at Microsoft.BizTalk.Deployment.BizTalkAssembly.GacInstall(String assemblyLocation)

  at Microsoft.BizTalk.Deployment.BizTalkAssembly.PrivateDeploy(String server, String database, String assemblyPathname, String applicationName)

  at Microsoft.BizTalk.Deployment.BizTalkAssembly.Deploy(Boolean redeploy, String server, String database, String assemblyPathname, String group, String applicationName, ApplicationLog log)


# Alex said on August 19, 2010 01:46 AM:

Hey man this is great, i'm having an issue with WCF adapters when I try to deploy bindings it keeps sending me the message "Failed to create 'WCF-Custom' Transport Component" any clues??

I've deleted my WCF-Custom ports to retry and also WCF-WSHttp cannot be created, i'm guessing an issue with WCF but it's on the ImportBindingWithValidation which is on  the class Microsoft.BizTalk.Deployment.DeployerComponent (aka Microsoft side) any tips??


# QuickLearn Team Blog said on December 9, 2010 06:40 PM:

Automated Deployment and Testing of BizTalk Server 2010 Applications

# RiteshC said on January 25, 2011 07:49 PM:

How to start or stop a running application? How to selectively start some port/orchestrations after I deploy my app? I have need to check if the application is running before I undeploy it.

I have been using SDC Tasks from codeplex and it was working good for me. But SDC Tasks worked good only for BizTalk 2006. Moreover it used ExplorerOM for these operations and ExplorerOM doesnt support 64bit platform. So, when I moved to BizTalk 2009 on 64bit platform, I am loosing these couple of tasks that I meintioed above. How can we include above 2 tasks - Starting/Stopping applicaitons/orchestrations and selectively starting ports/orchs in the build scripts you provided?

Anyway, this is a great post where we dont need to DEVENV.EXE to build out solution.

# wmmihaa said on January 25, 2011 08:19 PM:

You can still have custom tasks using ExplorerOM running on an x86 platform. Just make sure to build the task for x86.

This Blog


    MVP - Microsoft Most Valuable Professional BizTalk User Group Sweden BizTalk blogdoc

    Follow me on Twitter Meet me at TechEd


    Locations of visitors to this page


    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.