Preventing Stale Artifacts in BizTalk Application Packages

Written by

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

Comments

14 responses to “Preventing Stale Artifacts in BizTalk Application Packages”

July 19, 2007

Vamsi K

Hello Richard,

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

Thanks,
Vamsi K

Reply
July 19, 2007

Richard Seroter

Hey Vamsi,
Just checked on a few different machines, and looks like the images show up. Try again 😉

Reply
July 20, 2007

Mauro Sagratella’s Thoughts : Articoli interessanti su BizTalk

[…] e vengono dati dei suggerimenti per poter scegliere tra l’uno o l’altra a seconda dei casi. Il secondo è di Richard Seroter e nell’articolo viene dettagliata la modalità con la quale BizTalk mantiene […]

Reply
October 3, 2007

Sune Hansen

Thanks a lot for the great post clarifying something that has been puzzling me for quite some time.

/Sune

Reply
October 3, 2007

Richard Seroter

My pleasure. Glad to help out.

Reply
October 12, 2007

Maurits Billiet

This is all clearly stated in the documentation (see http://msdn2.microsoft.com/en-us/library/aa578101.aspx).

Reply
October 12, 2007

Richard Seroter

Ah, but that requires us to actually READ all the documentation! Thanks for linking to that.

Reply
March 5, 2008

Robert Southern

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

Reply
March 6, 2008

Richard Seroter

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.

Reply
March 17, 2008

Robert Southern

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.

Reply
November 4, 2008

Tarun Mistry

Once again Richard your blog saves the day!

Many thanks
Tarun

Reply
December 17, 2008

noshe ro

Could you please explain what is the ID field in adpl_sat stands for?

Reply
December 17, 2008

Richard Seroter

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?

Reply
December 18, 2008

moshe ro

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.

Reply