A misunderstanding about how BizTalk builds MSI packages for applications caused me some recent heartache.
Let’s say I have a BizTalk “application” with the following resources:
As you can see, I’ve got a BizTalk assembly, a “standard” .NET assembly, binding file, text file, and virtual directory (for a web service). In my simple mind, I see the “Source Location” column, and assume that when I walk through the wizard to build an MSI package, BizTalk goes and grabs the file from that location and jams it into the final package.
I was quite wrong. I learned this when I made updates to my web service and helper components, rebuilt my MSI package, deployed it, and learned to my horror that “old” components had been installed on the destination server. What gives?
Whenever you add a “resource” to a BizTalk application (either by deploying your BizTalk library, or manually adding an artifact), it is added to a CAB file and stored in the database. In the BizTalkMgmtDb database there is an amazingly well-hidden table named adpl_sat which holds these uploaded resources.
You can see in that picture that properties for each artifact are stored (e.g. GAC-ing components on install), and there’s also a column called “cabContent” which stores binary data. Updating artifacts on your file system does NOT mean they will get included in your MSI packages.
So what’s a guy to do? Well, you may have noticed that for most resources, when you right-click and choose “Modify”, there is a button where you can “Refresh”. Now, instead of just refreshing the file from the spot designated in the “Source Location”, it asks you to browse to where the updated file resides. That seems a bit unnecessary, but whatever.
So, that’s how you refresh MOST resources and make sure that your BizTalk application stays in sync with your developed artifacts. A big gotcha is, you CANNOT do this for virtual directories. I can’t seem to identify any way to refresh a modified web service short of removing the resource, and adding it back in. Big pain. Given how crucial web services are to many BizTalk applications, I would think that both adding them as resources (via UI vs. command line), and easily refreshing them, should be a priority for future releases.
Technorati Tags: BizTalk
Richard Seroter's Architecture Musings 
Hello Richard,
Thanks a lot for the tip.But I cannot see any images in this blog. Could you please correct.
Thanks,
Vamsi K
Hey Vamsi,
Just checked on a few different machines, and looks like the images show up. Try again 😉
Thanks a lot for the great post clarifying something that has been puzzling me for quite some time.
/Sune
My pleasure. Glad to help out.
This is all clearly stated in the documentation (see http://msdn2.microsoft.com/en-us/library/aa578101.aspx).
Ah, but that requires us to actually READ all the documentation! Thanks for linking to that.
Richard,
Thanks for this post, it helped me understand my deployment issues. I was wondering if you have done any research on how to refresh resources programatically. I have looked around and perhaps I am blind, but I cannot locate any information on this. The ExplorerOM would seem the most logical candidate, but Resources seem to be missing. Ideally, with a large quantity of resources that need to be refreshed, a script and a helper class would be ideal. Any thoughts?
Thanks again,
RRS
Good question Robert. You’d think that this would be exposed via script or the .NET based API. Looks like you’d have to use the BTSTask tool and execute a “RemoveResource” command followed by an “AddResource” command.
Thanks. Unfortunately, there are subtle differences between Remove/Add and Refresh. In particular, the issues surround the dependencies. The root of my problem lies in the pain associated to making minor changes to underlying artifacts and the need for parallel versioning with long running transactions. If, for instance, I have a long running process and I make a minor tweak to an underlying schema (like adding an optional element), it is extremely painful to update the orchestration too. In a Dev environment, you can build, GAC, and restart the Host Instance for a minor change. However, getting that loaded so that you can pull the MSI is more tricky. Refreshing the resource from the MMC allows you to load just that assembly without all the dependencies.
Once again Richard your blog saves the day!
Many thanks
Tarun
Could you please explain what is the ID field in adpl_sat stands for?
Hey moshero,
I have no idea what the ID is for in that table or how it’s specifically used. What were you looking to do with this information?
Hi,
Actually ,I’m looking for a solution to the next problem:
I need to remove the whole dll’s from the applications from my production machine,and deploy new dll’s from the QA machine to the production machine.
I thought to use the MSI in the following way :
make a MSI export of each application (in the QA) and make a MSI import in the production machine .
The Problem I’m facing is ,that I have dependency between dll’s that are located in different Applications .
This dependency force me to pay attention to the Import MSI order .
I can verify this dependencies from the BizTalk MngmntDB .
But still I need to create a complicated tree.