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

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
where did you sequence the "removeexisting products" action ?
Answered 02/07/2011 by: cygan
Fifth Degree Brown Belt

Please log in to comment
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?
Answered 02/07/2011 by: Superfreak3
Black Belt

Please log in to comment
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.
Answered 02/07/2011 by: VBScab
Red Belt

Please log in to comment
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).
Answered 02/07/2011 by: Superfreak3
Black Belt

Please log in to comment
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
Answered 02/07/2011 by: pjgeutjens
Red Belt

Please log in to comment
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.
Answered 02/07/2011 by: Superfreak3
Black Belt

Please log in to comment
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.
Answered 02/07/2011 by: Superfreak3
Black Belt

Please log in to comment
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.
Answered 02/07/2011 by: Superfreak3
Black Belt

Please log in to comment
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.
Answered 02/07/2011 by: WiseAppPackager
Purple Belt

Please log in to comment
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!
Answered 02/08/2011 by: Superfreak3
Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity