8 replies to this topic

[Superfreak3]

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!

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?

Edited by Superfreak3, 07 February 2011 - 17:24.

[Stefan Krueger]

Does the componentID match for this file between the old and the new version?

What does the log say about the file? (maybe: don't install because same version already exists - then - removing existing file during major upgrade)? In this case it might helöp moving the RemoveExistingProducts action after the installation of the new version.

[Superfreak3]

I'm almost certain the component codes don't match from previous to current release. The current release would have the component code assigned by Installshield when added. If it was the same as the code of previous releases, that would be like lightening striking.

I'll check the log to see what was causing the problem.

[Superfreak3]

I have the log with the previous version installed with Major Upgrade to latest version. The component in both cases is regtlb.exe.

The problem is that the log is 1.3 MB zipped so I guess I can't attach it here anyway.

Can I dump this somewhere for anyone to take a look at?

I did notice that most of the components had Action:Local, but the regtlb.exe component had Action:Null. What setting does that come from. When I look at the old and new install templates, both seem to be favor local.

I have to check for sure to see if the :Null reference descirbed above is listed during the uninstall or reinstall of the newer version.

If someone can take a look, let me now.

Thanks!

Edited by Superfreak3, 07 February 2011 - 22:49.

[Superfreak3]

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.

[Superfreak3]

I am so sorry for all the posts, but my mind is racing...

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.

Our new install has the features organized as...

Core
Integrations
PlugIns

where Integrations/PlugIns are subfeatures of Core. In this scenario, when a repair runs for a broken component that's part of the Core feature, does the repair trickle down to the subfeatures? From my testing, that's not the case.

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.

Edited by Superfreak3, 08 February 2011 - 03:21.

[Stefan Krueger]

Please send me the log by e-mail to skrueger (at) installsite (dot) org. I'll have a look and post relevant quotes here.

[Superfreak3]

Thanks Stefan! Email sent!!!

I did seem to track most of my problems down (I think.). 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 and/or InstallShield 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 possibility either.

Thanks again for taking a look!

[Stefan Krueger]

Regarding Action: Null - are you talking about entries like this: