cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Superfreak3
Level 11

Component Not Installing 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!

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?
Labels (1)
0 Kudos
(10) Replies
Superfreak3
Level 11

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.
0 Kudos
Superfreak3
Level 11

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.
0 Kudos
enanrum
Level 9

Did you ever get this resolved? How are you packaging your new release? I'm relatively new to MSI but I would assume you would have to play around with your Product Version, Product Code, Upgrade Code, (and Package Code - which should for the most part always generate new code)

Regards,
Tom
0 Kudos
Superfreak3
Level 11

As a best practice I had Dev. bump versions to reflect our current release where needed.

I then went one step further and moved RemoveExistingProducts earlier in the sequence so that a Major Upgrade will be similar to removal via Add Remove Programs.
0 Kudos
hoferat87
Level 3

I have encountered a similar problem a few times. The problem was always a component that existed in multiple versions but had a different componentId in the newest version. Updating the componentId in the new version so that it matched the componentId in the older versions always solved the problem.

You can compare the componentIds and all the other component info using the direct editor in installshield or with ORCA if your working with a MSI DB.
0 Kudos
Superfreak3
Level 11

Yes, I understand how that works, but in my case most if not all of the Component GUIDs will have changed because it's a rebuild of a Wise project with InstallShield.

At any rate, it is my opinion that a Major Upgrade should not undertake any GUID/install state comparisons. It should be complete removal based on involved codes and re-install. Moving RemoveExistingProducts earlier in the sequence accomplishes this.
0 Kudos
TheResearch
Level 6

Where is the RemoveExistingProducts sequenced in your installation?
0 Kudos
Superfreak3
Level 11

Immediately following ValidateProductID/Immediately before CostInitialize.

This sequencing better mimics removal of the product via Add Remove Programs (wiped clean).
0 Kudos
KathyMorey
Level 10

I have run into this, and found this to be my issue

File Version did not change between releases.

Major upgrade starts. Install file costing marks component as already existing.

Uninstall removes file.

Install skips file because it is marked as not needed.

Look in the log for the file name and you should see an entry that tells you the file is being skipped because it already exists with the same version.

Changing the file version of the file should resolve it, or, if you don't want to do that, changing the component GUID so Windows Installer thinks it is a new file may also work.

Or you can move the RemoveExistingProducts action to happen later, so it's an install-remove obsolete rather that a uninstall completely-reinstall scenario.
0 Kudos
Superfreak3
Level 11

KathyMorey wrote:
Or you can move the RemoveExistingProducts action to happen later, so it's an install-remove obsolete rather that a uninstall completely-reinstall scenario.


I have tried the install-remove obsolete scenario in the past, and I've also run into trouble with 'stuff' being removed that shouldn't have been. That's why I choose the complete re-install method.
0 Kudos