This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Upgrade not working: components missing?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 25, 2012
11:26 PM
Upgrade not working: components missing?
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
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)
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
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 28, 2012
12:58 AM
My recommendation is to avoid using dynamic links.
See: http://community.flexerasoftware.com/showthread.php?t=190497
See: http://community.flexerasoftware.com/showthread.php?t=190497
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 02, 2012
12:44 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2012
10:22 PM
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.
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.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)