Preventing Stale Artifacts in BizTalk Application Packages

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:

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

14 thoughts

  1. Hello Richard,

    Thanks a lot for the tip.But I cannot see any images in this blog. Could you please correct.

    Vamsi K

  2. 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,

  3. 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.

  4. 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.

  5. 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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.