For some time I have been wondering what assemblies exactly are included when a MSI package is exported in BizTalk. When moving assemblies for one environment to another I had noticed, that I didn’t always get the latest version of the assembly included in the package.
For BizTalk to function properly the assemblies must be deployed to the Global Assembly Cache (GAC). This copy of the assembly is the one actually being used during execution, but apparently it wasn’t the one being included in the MSI package. However, In the BizTalk Administration Console for an application’s resources there are both a Source Location as well as a Destination Location pointing to a copy of the assemblies as well. Thus my first thought was that perhaps, it was one of these that were included in the MSI package.
To test this I tried to delete first one of them, and then the other. Either way I was still able to generate the MSI package, which meant that it were neither of these that were being used.
Increasingly puzzled I ended up turning to the good old newsgroups for some help. It took BizTalk MVP Tomas Restrepo less than 1½ hour to point me to an explanation, and apparently I was not the only one a bit puzzled by this. The explanation was another blog post by Richard Seroter titled Preventing Stale Artifacts in BizTalk Application Packages.
In here he explains what is actually going on when assemblies are deployed and how the MSI packages are generated. Interestingly and, at least to me, also quite surprising as first are, that the assemblies are added to a CAB file and stored in a table in the BizTalkMgmtDb database. For the full explanation I encourage you to read the post.
One obvious advantage of storing this information in the database is of course that you can be sure that in a multi-server environment regardless of which server you use to generate your MSI package will always be exactly the same. However, whether this is the only reason for the implementation I do not know.