This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Component Not Installing After Major Upgrade...
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 07, 2011
10:02 AM
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?
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?
(10) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 07, 2011
04:01 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 07, 2011
05:16 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 27, 2011
10:08 AM
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
Regards,
Tom
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2011
03:42 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 08, 2011
08:40 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 08, 2011
08:46 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 11, 2011
05:45 AM
Where is the RemoveExistingProducts sequenced in your installation?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 11, 2011
08:26 AM
Immediately following ValidateProductID/Immediately before CostInitialize.
This sequencing better mimics removal of the product via Add Remove Programs (wiped clean).
This sequencing better mimics removal of the product via Add Remove Programs (wiped clean).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 14, 2011
09:18 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 14, 2011
09:24 AM
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.
