Upgrade not working: components missing?

[bornali]

Hello,

We are having upgrade issues. We have products say a, b c, d ,e etc. For each we had initially created installers in IS 2009.
We upgraded them to IS 2012, Basic MSI.
The head branch of development works fine. We then branched( say BRANCH 1.0) and intead of including JDK 1.6.20 we are nowincluding JDK 1.6.33. The files have been always linked dynamically. I believe the change classifies as a small update.
Fresh installs work fine on the branch. But upgrades don't..for some (ie product a, d, e upgrade but not product b, c for example).
The message obtained in msi log is:

SELMGR: ComponentId '{1C0DB29E-E5FB-CB4D-BD98-C2CD223BFB54}' is registered to feature 'PRODUCT_B', but is not present in the Component table. Removal of components from a feature is not supported!
MSI (c) (DC:D8) [13:24:19:054]: SELMGR: Removal of a component from a feature is not supported


This is how I changed between head and branch by just openening the ism file and replacing where ever there was occurences of JDK 1.6.20 to JDK 1.6.33 including the "Component" section (the componentID stayed the same)

AllOtherFiles3{F7DDB73B-657C-4FC5-BD41-2F5443EFC26B}JDK1.6.0_201617/LogFile=/LogFile=/LogFile=/LogFile=

AllOtherFiles3{F7DDB73B-657C-4FC5-BD41-2F5443EFC26B}JDK1.6.0_331617/LogFile=/LogFile=/LogFile=/LogFile=

What am I doing wrong? How can I replace a component's content? And how can i find out what this componentid is referring to (couldn't find this id anywhere else).
Changing product code and product version is not an option for us, as that will disturb upgrades between branch and head installers.
We are using setup.exe not msi, we could include MSI command line argument in the package to have REINSTALLMODE set to amus (though not recommended), but from what I know, the executable is not smart enough to not include these arguments when it is NOT an upgrade.


Thanks

[Magnus]

My recommendation is to avoid using dynamic links.

See: http://community.flexerasoftware.com/showthread.php?t=190497

[Sairen]

Magnus is spot on. Dynamic file linking can lead to a lot of trouble if you're doing minor updates.

Here's what happened. In your first version, the one with the older JDK, you likely included a bunch of files dynamically. It creates a set of component codes for the subfolders. These do not appear in your project's Direct Editor. You can, however, confirm their existence by looking at the extracted MSI in one of your running installations. They'll start with an underscore and be all caps.

Then, when you changed to using the newer JDK, the component codes changed. Some of them went away. There's the problem. Typical behaviors you'll see now include versioned files not being updated, new files not getting installed, uninstallations not removing any files at all, and of course, the SELMGR warning.

At this point, you have a couple options. If you possibly can, the simplest way is to change the product code and make it a major upgrade between the two versions.
You can also mandate that everyone uninstall and reinstall between those two versions, instead of upgrading. Customers tend to hate that, but we'll do it internally sometimes during development.
Finally, you can go back through the old version and add a dummy component with the missing component GUID for everything that was changed / removed. A tool like Msi Diff will make this a little easier, but it's still going to be painful.

And avoiding it in the future? On the rare occasions I do use dynamic linking, I never ever ever ... EVER EVER... ever... let it link subfolders. That way I can control my components.

Good luck.

[bornali]

thanks for the help.
The update validation wizard came in very handy(which i didn't know existed)
It provided the val0006 and val0001 errors telling which folders were causing the issue.
When i looked closer, these folders were getting created with a build timestamp at the end. As they were dynamically linked, it couldn't find the same folder in the later setup, and was asking to author the removal of that folder in the RemoveFile table(which i can't as folder name wouldn't be known untill build time). So this was fixed by changing our builds (to not have any timestamp) for such folders.