Software Deployment

where did you sequence the "removeexisting products" action ?

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?

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.

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).

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

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.

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.

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.

Have you tried changing/regenerating the GUID of the component which is causing issues and then install?
I hope, it could solve your issue.

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!