(Update: See the latest on the Deployment Framework here.)
It has been about three months since my initial submission to the BizTalk 2004 developer
competition that I discussed here.
The contents of that contest entry took a prize (woohoo!) but still left a lot to
Since then, I’ve had a chance to make what I believe are major improvements
to the deployment story I’ve been discussing since last May. In addition,
I’ve had a chance to see the practice being used across several large BizTalk
projects, and have done a lot of learning as a result. (No guarantees or warranty
implied, but derivatives of the scripts/tools I discuss here have been in use for
some time by a very large BizTalk customer I work with.)
The most important changes you will see in this release are as follows:
The “core” NAnt functionality has now been separated from the piece that
an individual BizTalk project must “own” and maintain. This is a
huge simplification, and allows for more rapid adoption — as well as the ability
to deploy bug fixes & feature enhancements in a way that just wasn’t possible
when stuff was intermingled. (Peter Provost was right about
that aspect of my first attempts.) The NAnt script that a particular project
must own can now be reduced to the following for a simple case (notice the ‘include’
reference for the core):
<project name="BizTalkSample" default="debugDeploy">
<-- Set following properties to true or false to
include various pieces of a BizTalk deployment. -->
<property name="includeSchemas" value="true" />
<property name="includeOrchestrations" value="true" />
<property name="includeTransforms" value="true" />
<property name="includePipelines" value="true" />
<property name="includeComponents" value="true" />
<property name="includePipelineComponents" value="false" />
<property name="includeCustomFunctoids" value="false" />
<property name="includeVocabAndRules" value="false" />
<property name="includeVirtualDirectories" value="true" />
<property name="includeMessagingBindings" value="true" />
<property name="includeDeploymentTest" value="true" />
<property name="includeCustomTarget" value="true" />
You now have the ability to supply a simple xml-driven Wizard-based UI when you are
deploying after an MSI install. You can use this UI to gather
Windows identity information for virtual directories (for SOAP/HTTP receive ports),
to indicate whether the scripts should deploy to the BizTalk management database (for
working in BizTalk groups), and for many other purposes. I call this “Install-Time
Configuration” in the documentation below. Here are some example Wizard
You now have the ability to have an Operations-managed “spreadsheet-driven”
mechanism for environment-relative configuration. What do I mean? I mean
those aspects of your deployment that are particular to your development, QA, or production
BizTalk environments. Aspects that wind up appearing in your BizTalk binding
files! Queue names, database names, file shares, FTP locations, etc. This
is information that you don’t want to manage with the Wizard UI above (there
is too much of it) and you want to maintain “as a set” for each environment.
The spreadsheet (pictured below) can start life with your developers, and ownership
can gradually migrate to Operations. This spreadsheet generates environment-specific
“settings” files, and at the point you deploy, the values for the environment
you are deploying to are automatically substituted into your binding file…Slick!
You now can use a highly templated (reusable) WiX based
setup, rather than a Visual Studio Setup Project, to generate your MSI. WiX,
in a nutshell, is a set of tools and an Xml grammar that allow you to specify the
contents of an MSI. One of the clear pieces of feedback I got on the last rev
I released is that reproducing a Visual Studio Setup Project was far too manual.
There are a large number of other changes that I’ll just enumerate quickly
You no longer need to have your NAnt file enumerate your orchestration names or
their deployment order – a new custom NAnt task eliminates the need for
You no longer need to have your NAnt file enumerate how many receive ports/send
ports/etc. you have – a new custom NAnt task eliminates the need for this.
Support for BizTalk groups, where machines 2-n do not require deploying to the BizTalk
Support for not following the naming recommendations I made in previous releases –
you can have custom project names, assembly names, directory names – its just
a little more work.
Support for multiple assemblies of the various types (i.e. multiple orchestration
assemblies, schema assemblies, etc.)
Inclusion of a utility I call SetEnvUI.exe for creating the xml-based wizards described
Inclusion of a utility I call DeployBTRules.exe for deploying BizTalk Rule Engine
policies and vocabularies.
Inclusion of Loren Halvorsen’s XmlPreProcess tool
for managing the environment-relative configuration discussed above.
Support for creating IIS6 application pools (with specified Windows identity) for
HTTP and SOAP-based receive locations, and for adding virtual directories to application
- Support for registering the btshttpreceive.dll ISAPI extension with IIS6.
Support for selectively restarting multiple BizTalk host instances, for deploying
custom functoids, and for dealing with send port groups, and more…
There are now two downloads. The first contains all of the core scripts and
utilities plus a sample BizTalk solution that uses them. The second download
contains just the core scripts and utilities, and is designed to allow a BizTalk solution
to accept updates/bug-fixes/etc. over time (i.e. the zip can be expanded into your
directory structure on a developer workstation so you can test it out.)
It should be noted, though, that some manual work will be required to “upgrade”
from the previous version I released in September – this release is quite different,
but I think you will find it is well worth the time.
Full download is here.
Core scripts and utilities only are here.
GotDotNet Workspace is here.
The full documentation for this release (which includes more detail than this blog
entry…) is included in the zip files, but it can be viewed directly here (with
a diagram here.)
Enjoy! And remember: if you didn’t make into a given environment (QA,
production, etc.) with a scripted deployment of some kind, you didn’t get there
(Not necessarily this stuff, but something automated, at any rate…)