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.