Copyright © 2008-2019 Paula DiTallo

Tag Cloud

Why am I getting a binding error on an *.msi file for a re-deployment of a BizTalk application that doesn't contain any bindings?

When this dreaded error crops up, its usually right in the midst of a fast and furious development effort. That's always been the case for me! To solve it in a hurry, I just dub the app with a higher version number, recompile and move on--at least that is what I did when I was a bts developer. Now that I'm a bts admin, I've delved into the topic more. Although the re-versioning scenario works, it is possible to re-deploy an *.msi package with the same version number using these few steps:

  1. Go to \Documents and Settings\[deployment acct username]\Application Data\Microsoft\BizTalk Server\Deployment\BindingFiles. (READ: you should see 2 on a reploy, one with a tilda [~]; 1 without)
  2. Since a new app with a new version # creates a BindingInfo xml file on an initial deployment, rename the one you find there to something else. Get rid of the new one (file without the ~) that failed.
  3. Import/re-deploy the *.msi file again.

Why do these steps  work? It appears that new app deployments create the Binding.Info.xml file based on the initial assembly reflection which has the orchestrations, etc.  -- however -- when you redeploy an existing app, the binding file gets generated based on the details stored in the bts management database (BizTalkMgmt)  for that  existing assembly. The  binding file that gets generated from that process is the one  without the ~. 

When you get rid of the base/initial bindings file, bts does not try to apply the bindings it expects to find  (even if there aren't any)  like it does the first time it recognizes the file.

These steps should solve the "ghost" bindings issue, but if not for some reason, there's always the tried and true re-versioning of the app!! 




Sunday, January 25, 2009 12:57 PM


No comments posted yet.

Post A Comment