Video Screencast Help
Search Video Help Close Back
to help
Not able to make it to Vision this year? Get a sampling in the Best of Vision on Demand group.

avoiding an orphan component or broken product

Updated: 03 Oct 2010 | 3 comments
Alan Sinclair 2's picture
0 0 Votes
Login to vote

Can anyone think of a solution to this knotty problem?

We ship a program as a merge module, used by various OEMs in their products. An end-user may install several different products that include our program. Thanks to Windows Installer, only the latest version of our program will be active.

Until now our product's components have never changed when new file versions are built.  But now, after many years we need to add a component to our program. So there are complications:

Say Product A includes our component X, and Product B includes our component X plus our component Y.

If a user installs both A and B, they have components X and Y. If the user later uninstalls A everything is fine, X and Y are still on disk and B works. 

However, if B is uninstalled first, leaving A in place, then Y will be removed which breaks our program and product A.

One approach might be to use a custom action in the new mergemod to manipulate the SharedDlls reference count for Y, so msiexec doesn't remove it when B is uninstalled:

e.g.  IF refcountX > 1 and refcountY = 1 THEN increment refcountY

This will leave component Y orphaned after A and B are both uninstalled, which isn't very tidy but avoids breaking things. But it only works if A is installed before B.

Is there a better solution?

Discussion Filed Under:

Comments

EdT's picture
29
Mar
2010
0 Votes 0
Login to vote

I don't see the problem

Product A installs component X
Product B installs component X (actually increases reference count for X) and installs Component Y.

Uninstall Product B and Component Y is removed, and Component X has reference count decremented, so why is Product A, which has no dependency on Component Y, left broken?

Any way I look at it, regardless of what order A and B are installed in or removed in, the remaining components continue to support the remaining product.

Hence either you have missed something vital in the explanation, or I have missed seeing something in your current explanation.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Alan Sinclair 2's picture
29
Mar
2010
0 Votes 0
Login to vote

I clearly wasn't giving a

I clearly wasn't giving a clear explanation ... the (missing) vital bit is that when B installs Component X, that's a newer version of X than was previously installed, and unfortunately the new X requires component Y.

You've put your finger on the flaw in our program of course: the new X should not be dependent on Y. I'll have to go back to the developer and try for a redesign. But the setup was (yet again) left until after the program was developed, so it's unlikely to get redone and I'll have to do grubby stuff.

EdT's picture
01
Apr
2010
0 Votes 0
Login to vote

Give the developers a good

Give the developers a good kicking and make sure they pay for a lot of beer if you end up having to do grubby stuff (again).

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.