File this under “I didn’t know that!” Did you know that if you add multiple BizTalk binding files (which all target the same environment) to an application, that they ALL get applied during installation? Let’s talk about this.
So I have a simple application with a few messaging ports. I then generated four distinct binding files out of this application:
- Receive ports only (dev environment port configurations)
- Send ports only (dev environment port configurations)
- Send ports only (test environment port configurations)
- Send ports only (all environment port configurations)
The last binding (“all environment port configurations”) includes a single send port that should exist in every BizTalk environment.
Now I added each binding file to the existing BizTalk application while setting environment designations for each one. For the first two I set the environment to “dev”, set the next send port binding to “test” and left the final send port (“all”) with an empty target (which in turn defaults to ENV:ALL).
Next I exported an MSI package and chose to keep all bindings in this package.
Then I deleted the existing BizTalk application so that I could test my new MSI package. During installation of the MSI, we are asked for which environment we wish to target. I chose “dev” which means that both binding files targeted to “dev” should apply, AND, the binding file with no designation should also come into play.
Sure enough, if I view my application details in the BizTalk Administration Console, we can see that a full set of messaging artifacts were added. Three different binding files were consumed during this installation.
So why does this matter? I can foresee multiple valuable uses of this technique. You could maintain distinct binding files for each artifact type (e.g. send ports, receive ports, orchestrations, rules, resources, pipelines, etc) and choose to include some or all of these in each exported MSI. For incremental upgrades, it’s much nicer to only include the impacted binding artifact. This provides a much cleaner level of granularity that helps us avoid unnecessarily overwriting unchanged configuration items. In the future, it would be great if the BizTalk Admin Console itself would export targeted bindings (by artifact type), but at least the Console respects the import of segmented bindings.
Have you ever used this technique before?
Technorati Tags: BizTalk
Richard Seroter's Architecture Musings 
I’ve used this several times, and it’s nice (though a pain in the neck to maintain all the binding files). However, one thing to watch out for: Make sure you un-configure the application completely before exporting it.
Otherwise, when you import the MSI, BizTalk will try to first apply the original bindings (i.e. whatever the app was configured with at the time of export) and *then* apply the selected environment-specific binding files over that, which will not work most of the time.
Hey Tomas,
But if you don’t select that last “Binding” option during export, that shouldn’t happen. If you keep it selected, then a default binding (matching the current configuration) is added to the MSI. That screwed me up a few times …
Probably true. I just got it wrong so many times that it was easier to remember to just unconfigure everything before the export 🙂
This is pretty cool. We’ve got some monster binding files and I forsee using this technique to help us chunk up logical portions of the application (ie, Customer Master, Order Management, etc.). This will also help make branching and merging a little easier too. Thanks for the post!
This sounds great but unfortunately does not work in practice.
I split my bindings files for each environment into “core” and “test” bindings.
Basically the core bindings contain everything needed for the application to run, and the test bindings contain just the things necessary for running the bizunit tests.
Then I baked the bindings for all the environments into an MSI.
So in the resources view of the application is somthing like:
CoreBindings.xml—————-ENV:Development
TestBindings.xml—————-ENV:Development
CoreBindings.xml—————-ENV:SystemTest
CoreBindings.xml—————-ENV:Production
However, when selecting the SystemTest option from the environment dropdown when importing the MSI something strange happened.
The core bindings (with the SystemTest settings) were applied, but so were the test bindings (with the Developement settings)!
This seems to be something that BizTalk does which is very weird. But there you go…
Could that have something to do with naming? Since you have CoreBindings.xml as the name for three distinct environments, it may use all the bindings with that name.
Sorry the post was misleading in that I was simplifying an example. The actual bindings files are all differerntly named.
Actually I have worked out the reason why. We have a problem in our custom MSBuild tasks which does things in the wrong order. Sorry for the idiocy.
To clarify, we have a problem in our custom MSBuild tasks which adds the bindings as resources, then applies the wrong bindings with BTSTask before the MSI is exported WITH the bindings. So the exported MSI has the wrong bindings regardless of which environment is selected on import.