/build/static/layout/Breadcrumb_cap_w.png

Component Not Installed after Major Upgrade...???

Hi all,

I have something weird going on with a Major Upgrade. We've just switched back to InstallShield (2010) from Wise and we are ripping out our old application.

We are set in InstallShield to completely remove old first. Everything appears to go OK, but on initial launch, we get the repair. After further investigation, there is a component that should be installed, but it is not for some reason.

It is part of a feature that is installed and there are not conditions on it. There is a Custom Action that calls it, but it has a condition of $ComponentName=3. This action is set as Asynch, no wait so I don't know if its not set to install so the action doesn't run or if the Asynch, no wait setting just passes any errors if the file is not there when called.

What are some other reasons why this file may not be installed. I then tried just a fresh install without the major upgrade. When we install the latest version, the file in question is installed. Could it be getting confused with something still hanging form the version that was ripped out. I check the directory and it does get cleaned out so it shouldn't be a problem.

Any help is greatly appreciated!

Thanks!

0 Comments   [ + ] Show comments

Answers (10)

Posted by: cygan 13 years ago
Fifth Degree Brown Belt
0
where did you sequence the "removeexisting products" action ?
Posted by: Superfreak3 13 years ago
2nd Degree Black Belt
0
I let InstallShield do that by checking the remove old product first option in the Upgrades configuration. They put it right after InstallValidate. All of the stuff appears to be ripped before the upgrades starts dumping the latest stuff.

UPDATE: If I mark the component's key file property to always overwrite, it seems to work OK following Major Upgrade. The .exe is installed then with the latest version. This is a little widget that rarely changes and has the same version across releases of our application. Something must be hanging from the old app somewhere, right?
Posted by: anonymous_9363 13 years ago
Red Belt
0
Maybe in the previous release, the component is set to remain after an uninstall but the file gets removed in, say, the RemoveFile table? In that case, I think the registry data recording its installed state would still be present and thus the new release would skip it.
Posted by: Superfreak3 13 years ago
2nd Degree Black Belt
0
I checked the component containing it and it was not marked as permanent. And there was nothing in the RemoveFiles table.

I'm stumped on this one, but I guess I have a workaround. I have yet to try earlier versions of our software with Major Upgrades. I've only gone one release back for right now (the last built with Wise).
Posted by: pjgeutjens 13 years ago
Red Belt
0
I've seen similar behaviour from some packages in the past, where after the update a component (usually containing the main exe for the app) is just missing and you get a repair. I used to think this might be caused by a combination of locked files (the app is still active) upon uninstall of the old version, and the PendingFileRenameOperations cleaning up the file, even though it's the new one, but I've also heard it being described as a bug in InstallShield.

Anyway, our usual solution is to force a taskkill on the offending operation before the upgrade. Crude, I know, but it works...

PJ
Posted by: Superfreak3 13 years ago
2nd Degree Black Belt
0
I've been testing all of this from our version 8.0 or 8.2 to our new 8.3 release.

When I install v7.x and run the Major Upgrade to 8.3, the problem does not occur. Something must be amiss in the v8 prior releases.

I'm logging bot a major upgrade from v7 and v8 to see the differences. I hope I can tell.

I just want to be sure that changing the file to Always Overwrite is the safest most reliable way of working around the issue.

If I can't come to a conclusion from the logs, can someone take a look?

Any eyes would be GREATLY appreciated.
Posted by: Superfreak3 13 years ago
2nd Degree Black Belt
0
It seems this problem is going to be a little more difficult to tackle. When I look at the install log I see a bunch of Action: Null. The problem is this. I reorganized the Features with this release. The problem I was seeing is in the main feature. When I marked the involved file as Always Overwrite, the initial repair went away. But when I check for some files marked in the log with Action: Null, they were still missing. They are in a different feature. I guess they would get repaired when they're hit.

In our old install, everything was under one Feature so everything would have been repaired/replaced/fixed.

Reorganizing the feature shouldn't be a problem as this is a Major Upgrade so what gets placed as new shouldn't matter. It does seem that some previous release information is not being removed properly.

I'm at a loss at the moment. The only thing I can think of doing is placing everything in the Main Feature to test. Each file that triggers a repair would be marked as Always Overwrite and I would have to recompile, reinstall and work through all the problems one at a time. I sure hope Always Overwrite is the way to go.

Something is definitely not right and I have no idea what it could be.

To compound the issue, I'll have to test this on 64 bit also as there are separate features for that. I'll have to ensure that all the components are places properly there as well.
Posted by: Superfreak3 13 years ago
2nd Degree Black Belt
0
My feature tree looks like this....

Core
PlugIns
Integrations

The PlugIns and Integrations are sub features of Core. When a repair runs, if the broken component is part of the Core Feature, will the repair only act on that feature or will it trickle down to the sub features as well?

From my testing on this problem it appears it doesn't trickle down.
Posted by: WiseAppPackager 13 years ago
Purple Belt
0
Have you tried changing/regenerating the GUID of the component which is causing issues and then install?
I hope, it could solve your issue.
Posted by: Superfreak3 13 years ago
2nd Degree Black Belt
0
I wouldn't think the component codes would need changing since I just rebuilt our install with InstallShield from scratch so all GUIDS should be distinct from previous releases.

I did seem to track most of my problems down. For the most part, it boiled down to earlier versions of component key files being placed in my source area. I am having Development rectify those problem files.

However, this doesn't explain the whole issue. I am wondering, after a Major Upgrade, why previous file versions, etc should have any bearing on what is being placed with the more recent install. I thought when a Major Upgrade runs, old versions are REMOVED and the new installation is treated as a brand new product.

Either I'm not clear on the specifics of the Major Upgrade mechanism (which is most probably the case), there is an issue with Windows Installer when it comes to this, or there is something wrong (outside of the versioning problems) with my installation package(s). This is definitely not out of the realm of possibililty either. :D

Thanks for all the info, tips, suggestions!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ