(Update: The original download files were missing the PDB-to-GAC functionality
I’ve discussed before. Please download again if you have already…)
Deployment Framework has been updated to work with BizTalk 2006…It is hard to
believe that this project has been going on since May of 2004!
The Deployment Framework for BizTalk 2006 still has the same goals as the
- Streamline the deployment process for developers, ensuring repeatability
Make it easier for a team of BizTalk developers to stay in sync – not just with BizTalk
artifacts, but with all the other infrastructure that surrounds the solution (virtual
directories, queues, file folders, etc.)
Extremely close parity between server-side deployments and developer deployments –
so you are always testing your server deployments as you go through a typical developer
BizTalk 2006 itself introduced quite a few features to make deployment easier, and
can work fine for small (or solo) projects. Here are a few limitations I’ve
Though much improved, it is still possible to get into “dependency chaos” – where
you spend time manually undeploying/deploying individual artifacts.
Binding changes have to be communicated “manually” between developers on a team, since
the import process is done through the Admin MMC or command-line. Just “getting
latest” from version control isn’t sufficient.
Binding files for your various environments have to be maintained as separate files
(manually), rather than “merging in” environment-specific settings
Artifacts such as rules, virtual directories, queues, folders, additional dependent
assemblies, etc. can be represented as “Resources” within the Admin MMC (and in exported
MSIs), but not in a fashion that easily moves between developers on a team.
So! To get started with this version, download the Deployment
Framework (Tools) zip and run the MakeBizTalkExternalTools_VS2005.vbs script.
This will add entries to the Visual Studio tools menu for deploying and undeploying
using the framework. You can download the full
sample to see the framework in action (first build it, then do Tools-BizTalk
Deploy. You’ll see something like this.)
The high-level approach is the same as the 2004 framework – you supply a small project-specific
NAnt script that indicates via properties what elements of a deployment your solution
requires. You include BizTalkDeploymentInclude.nant to get all the core deployment functionality,
and make sure the DeployTools directory is copied to your project. (Unzipping
Framework Core into your project is a good way to do this.) See the documentation for
a more complete discussion.
The primary difference in the upgraded framework for BizTalk 2006 is that
we now create a BizTalk Application definition, and use BTSTask to
add all BizTalk artifacts as resources within that application. Starting and
stopping the application is done at an application level rather than per port/per
Packaging up your solution as an MSI can be done with the WiX-based scripts that have
been in the framework for awhile, or by using the MSI export mechanism in
BizTalk 2006, if you prefer. (The latter solution will require a few additional
steps, and doesn’t give you the parity described earlier. But it works if you
need to go that route.)
.85 RC4 (and NAntContrib )
is required. Be sure to copy the new BizTalk.NAnt.Tasks.dll to NAnt’s bin directory.
We need to call BizTalk’s .net 2.0 assemblies, and NAnt wasn’t built against 2.0 —
so change nant.exe.config to have only<supportedRuntime version=”v2.0.50727″
/> in the<startup> element.
Log4net usage in the sample (which isn’t required of course for the framework)
has been updated to log4net
1.2.10 , as has my serializable
wrapper. You can find the new log4net.Ext.Serializable in the Tools download
(which is useful all by itself, apart from the framework.)
You can actually use the BizTalkDeploymentInclude.nant file in this release with BizTalk
2004, if you like, to aid in your migration. There is NAnt property to indicate
2004 vs. 2006.
Scan all the previous
Leave comments with any questions/issues/etc. Enjoy!