Manual BizTalk Deployments and Assembly Version Mismatches
Deploying BizTalk applications have always been a little difficult. Things have improved greatly over the years with the Deployment Framework and similar time-savers, but in the end we still often find the need to go through the painful process of a manual deployment.
There are a few different ways to do this: Visual Studio, MSI, and adding the assemblies directly to name the most common. Of course, Visual Studio deployments aren’t usually practical outside of development environments. MSIs are most effective when you can deploy at the BizTalk Application level, but can be troublesome when you need a finer level of granularity. Although often the most difficult choice, adding the assemblies directly allows you deploy assemblies individually which can be useful (if time-consuming) with larger deployments.
The problem,of course, is that when you’re deploying something manually, especially when adding assemblies directly through the Add Resources dialog, you may sometimes forget steps in the process. I did such a manual deployment to update an existing BizTalk application. After deploying the updates, the application stopped working and BizTalk suspended messages with this exception:
A message sent to adapter “YOUR_ADAPTER” on send port “YOUR_SENDPORT” with URI “YOUR_URI” is suspended.
Error details: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
How did we lose a file? What file is it trying to access?
The updated assembly contained a new map and because the message was suspended on a port referencing that new map, that was the first place we looked. But the map had been deployed. It showed up in the Administration console. Odd…
The answer came to us by looking at the GAC. We found that the version of the assembly containing the new map in the GAC had a much earlier “Created Date” than the one we just deployed. So the BizTalk management DB had a record of our new map, but the GAC’d version of the assembly was a previous version that did not contain the new map.
So what happened?
When you manually add assemblies to BizTalk through the Administration console, you have the option to have any assemblies you deploy added to the GAC for you at the same time. This is done by selecting a checkbox in the Options section of the Add Resources dialog.
Here’s an example:
Note that the top item is selected and the “Add to the global assembly cache on add resouce (gacutil)” is checked. Some may make the assumption that the options selected here would apply to all the items in the list. However, that is not the case. Note what it looks like when another item is selected:
The checkbox is not selected. This is one of those easy misses that makes you feel foolish when you discover it. Fortunately, this was a pretty easy fix as we just needed to run GACUTIL to add the remaining assemblies to the GAC and the application worked correctly afterward.