On MSIs and Default Bindings
Some observations (I’ll you to draw your own conclusions, for a change) -
- When you import an MSI, any default binding in it will always be imported, then any binding matching the environment selected in the import MSI wizard (if selected)
- If the second binding contains any settings that were already created as part of the first binding, they will be overwritten
- When you export an MSI, a binding file is created with the existing configuration as the default binding, even if you did not add one as a resource explicitly. This binding will be imported first, before any other binding.
- In the case of receive locations – if two bindings in the MSI contain receive locations for the same port each marked as primary, the last one imported will be the primary receive location.
Why am I writing this?
We had an odd case (which shouldn’t really happen) where we created an application with a particular receive location.
We have then added a binding file for another environment in which we have misspelled the receive location name (the URI was the same)
When we tried to import the MSI to the second environment, selecting the environment name in the import MSI wizard we received an error that looked something like this -
(for the search engines: “Cannot update receive location”, “Address should be unique for Receive Location”)
The reason was that the wizard imported the MSI and initially applied the default binding creating the receive location with the first name. It then went on to import the second, environment specific, binding file, now trying to add a new receive location with the different name but failing as the URIs are the same. had the name been the same the receive location would have been overwritten, had the URI been different a second one would have been successfully added, but given this weird combination the error was produced.