MSBuild is the new build platform for Visual Studios. It allows great flexibility, customization (through creating custom Tasks), and integration with unit tests.

While MSBuild doesn’t directly support building BizTalk solutions, tasks are available to call the DEVENV executable and Microsoft UK has released a set of custom tasks to support a wide verity of common BizTalk tasks (available on GotDotNet). This provided an easy method for scripting automated or ad-hock BizTalk builds and deployments using MSBuild.

What can MSBuild do for you?

– Allow for automated and scheduled builds of your BizTalk code

– Extract code from Team Foundation Server (or other source control)

– Run unit tests

– Deploy BizTalk code to local or remote servers

– Control your overall BizTalk deployment by removing past solutions, stopping applications, and terminating Orchestrations

I have put together a sample to show the power and flexibility of using MSBuild for you BizTalk Build, Deployment, and Undeployment.

Download: BizTalk 2006 Build and Deployment with MSBuild

(Note the download included the custom BizTalk task binary files from GotDotNet and required license file.)

This solution provides a sample of how to set up a MSBuild script to build, deploy, and undeploy a BizTalk 2006 Solution. This solution has multiple projects and custom .net code. I also use MSBuild to create all required Send and Receive Ports and bind them to the Orchestration.

The whole build and deployment process does not use a MSI or a binding file. Although, I would have used a binding file but I wasn’t able to get the custom task to work correctly. This approach might not be the best solution to your deployment needs, but is intended to show you what can be done and how.

To run the sample, it must be extracted to your C drive unless you manually edit the configuration files. Once extracted, open a Visual Studio 2005 command window, change your path to C:\SampleDeployment, and type: MSBuild Build.proj to build and deploy the code. To undeploy the solution type: MSBuild UnDeploy.proj

The Build.proj will automatically do an undeployment if needed. This sample has only been tested with a local deployment and I was not able to get it to work remotely on my home environment. I need to do some more research on this.

In case you get lost in all the files, the FullBuild.proj is the full undeploy, build, and deploy in one file. All MSBuild files have been commented so it should be easy to follow what is going on.

Key files and what they do:

Build.proj – this is basically a control file. It imports Build.properties, Undeploy.targets, and Deploy.targets.

Undeploy.proj – this is another control file. It imports Build.properties and Deploy.targets. It is used if you just want to undeploy the solution.

Build.properties – this contains solution specific information like the solution name, dll names, application name, and so on. In theory, this should be the only file you need to update (except I hard coded all the port info into the Build.targets file)

Undeploy.targets – this set of targets handles the termination of running Orchestrations, stopping the Application, and removes the items from the GAC.

Deploy.targets – this set of targets builds the BizTalk solution, creates the Application, creates the ports, deploys the BizTalk assemblies, binds ports to the Orchestration, and starts the Application.

FullDeplou.proj – this file is the same as Build.properties, Undeploy.targets, and Deploy.targets except it has all the targets in one file.

One huge time saver I found when working with the custom tasks from GotDotNet is to download the source code. This way you can view the custom tasks, understand input parameters, and see required fields. It’s a huge time saver.

What’s on the horizon? Integration with BizUnit, FTS, multiple deployment options (like Dev, Test, Prod), and testing the remote deployment support. I hope to post more on these topics later on.