Upgrade not replacing old files; is there a problem if components renamed or moved between features

[DataAnalyzer]

We created a new setup, but it is not updating files from previously installed versions properly.

It has the same product and upgrade GUIDs as prior versions. And it installs new components. But it is not replacing the older files.

We could have renamed components or moved components to different features (which may also be new or renamed). Or moved files between components. Could such changes prevent the Upgrade Mode from replacing the old files with the newer ones?

[shunt]

Hi,

Microsofts Windows Installer has very strict rules about what can and cannot be changed depending on the upgrade type you are attempting.

As you have not changed the product code, this would be a Minor Upgrade which would not support the removal of components or Key files. Take a look at my video which explains the different Upgrade Types with pro's and cons for each.

Introduction to Windows Installer Upgrade Types:
https://community.flexera.com/t5/InstallShield-Knowledge-Base/Introduction-to-Windows-Installer-Upgrade-Types/ta-p/193041

I would suggest in this instance that you take a look at creating a Major Upgrade for your package.

I hope this helps,
Stuart

[DataAnalyzer]

Thank you for your response. I understand how a minor upgrade may not remove existing files but what would cause it to not replace files that are older than what's in the new setup?

It skips them for some reason and we were wondering if that's because we may have rearranged the files in the components and/or features. For instance, if the original installation used a component that was renamed in the newer version (even though they both have the same file names). But maybe the problem is caused by something else.

When the same setup is run for a clean machine, all the new files are installed so they are definitely in the setup.

[varul]

Hi @DataAnalyzer ,

 You can try to change the reinstall mode property value to amus and then create a build and try installing and verify it works or not,

First try to pass the reinstall mode property value using commandline and install your current setup and verify it works or not.

/v"REINSTALL=ALL REINSTALLMODE=amus" via cmd line.

Please check windows help page on reinstall property

https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode

https://learn.microsoft.com/en-us/windows/win32/msi/reinstall

[DataAnalyzer]

Thank you. What do you mean by changing the reinstall mode property value to amus? I thought setting a file to Always Overwrite would do that. Is that something we set in the ISM file? If so, how? Or is this just done through a command line?

What we've since discovered is that we did not change the names of components or features or move components between features. So that's not the cause of the problem.

We have 4 builds. Build 1 was the original, followed by builds 2 and 3. We now have Build 4. Build 4 updates Build 3 properly but fails to overwrite the files in Builds 1 and 2. Trying to figure out why. 

Thank you in advance for your insight and help.

[DataAnalyzer]

When we run the setup program with that command line, we get this message which is asking to uninstall the program which would eliminate all the user's current settings. We just want to update our files. Did I miss something?

[shunt]

Hi,

There is no definitive information from Microsoft that I can find that describes if changing just the component name requires a change of the product code (A major upgrade) or not.
In my experience I'm sure I have come across this before and found that this is the case as the Component name is shared across so many MSI tables and changing it causes a Minor Upgrade failure.
My recommendation would be to create a Major upgrade - alternatively if a Minor Upgrade is a necessity make sure the component names have not changed and all other upgrade rules have been followed.

Information on when the Product Code must be changed can be found here:
https://learn.microsoft.com/en-us/windows/win32/msi/changing-the-product-code

I hope this helps,
Stuart

[DataAnalyzer]

We discovered that the component and feature names did not change, so that's not the cause of the problem. We tried using a new product GUID to trigger a Major Upgrade, but that sends it into the main new installation process where they have to enter the credentials, choose features, installation folder, etc. that we don't want them to do for an upgrade.

We have 4 builds for this project. Our new Build 4 upgrades Build 3 without a problem, but doesn't overwrite any of the files in Builds 1 and 2 even though those files are much older. Most of our users are already on Build 3, but one never knows if someone didn't apply Build 3 when it became available. We were hoping Build 4 would upgrade all previous builds. Even worse, after Build 4 fails to overwrite those files, in the Programs and Features list, it shows the new build number implying it was successfully installed when it wasn't.

[ch_eng2]

This isn't going to help you now, but this is the very reason why we switched to InstallScript Only projects years ago - specifically because of the "Always Overwrite" option for components

 

[DataAnalyzer]

Thank you for your response. We are already using InstallShield scripts and still having this problem in spite of flagging it as Always Overwrite. Looking at the VERBOSE log files, it doesn't seem to even notice the old files to overwrite them in our older builds but it does for our most recent build. Very odd and confusing.

[ch_eng2]

Interesting. Any chance the Link Type for the problem component(s) is set to "Dynamic" instead of "Static"? We only use a Dynamic Link Type for a website component which we manually script some file deletions during a patch at the end of OnUpdateUIBefore(). Not ideal, but that is our workaround for the Dynamic link.

[DataAnalyzer]

Thanks. We have some dynamic linked files, but even the Static files aren't being overwritten against the older builds. Bizarre.