Need to disable ISPreventDowngrade

[Shobha_Dashotta]

Hi,

I want to be able to support "downgrade" in my installer. Essentially, need to support upgrade from the older 5.X version to the new 1.0 version. It is not a major upgrade so we are not changing the product code. But, the standard message of "Another version of the product is already installed ...." is displayed.

I made changes to the Upgrade table and made the min and max versions as " ALL VERSIONS". I even tried to remove the custom Action IsPreventDowngrade from the Install Sequence. But it continues to block the upgrade.

Any idea how I can make this possible?

Thanks
Shobha

[MichaelU]

If it is not a major upgrade, i.e. if the ProductCode is unchanged, then the entries in the Upgrade table are not relevant here. The message you mention sounds a lot like you're trying to install a minor upgrade without using the setup.exe bootstrap (or at least without passing proper REINSTALL commands).

In the versioning scenario you describe, I would probably change to a major upgrade (change the ProductCode) so that I could properly track version history. It's a lot easier to understand that {AAA-A-A-A} versions 1.x through 5.x come before version {BBB-B-B-B} version 1.y, than to try to figure out whether version 1.6 is before or after version 2.3 without such an indicator.

As I change the Product Code, I might also change the UpgradeCode, because then this is easier to describe in the Upgrade table; if I do that, I could keep the existing entries, and add one for the old UpgradeCode specifically targeting versions through 5.x. This is good for automatically detecting this scenario (although if you never changed the ProductCode before, it may be easier to process the action property looking for the old code), but may also prevent the older versions of the product from detecting the newer ones at all, leading to an unintended scenario where they install side by side.

[Shobha_Dashotta]

Thanks Michael.
Finally the the software upgrades from a previous (higher) version to a newer (lower) version with success. These are some of the other things I had to do after changing the product code.

1. Even if it is a major upgrade, we did not want to uninstall everything and then install but that was happening. So in a custom action after InstallValidate, I unset the value of REMOVE property as it was getting set to ALL. A custom action UnistallCommit had that condition set.

2. In the upgrade table, added the major upgrade item and set it any earlier version.

3. The install was happening fine but, something was going wrong in the end and this would rollback everything. After hours and hours digging through logs and looking online, I changed the sequence of the RemoveExistingProduct to above CostFinalize. This made the upgrade run successfully. Both the upgrade paths 5.x.y to 1.0.1 and 1.0.0 to 1.0.1 are now supported.

But now, I am unable to upgrade from 1.0.1.x to 1.0.1.x+y. The installer does not complain and I guess that's because it is comparing the first three fields only. This was happening earlier. How can I fix that ?

Thanks
Shobha

[TsungH]

If you have not, please refer to ProductVersion property.

[Shobha_Dashotta]

I have referred to that. The weird part is that before I added the support of "upgrade" from 5.x , the upgrade of 1.0.1.x to 1.0.1.y was working fine with no entries in the upgrade table.
If the windows Installer not using the fourth bit for comparison then it shouldn't have considered earlier too.


Thanks
Shobha

[DLee65]

We have a similar scenario in our work environment.

Product managers would like the installer version to reflect the file version. The problem is file version and file product version all use four sets of digits xxxx.xxxx.xxxx.xxxx. As you have noted, Windows installer reflects 255.255.65,535 maximum. It supports the display of the four set of digits, BUT the fourth set is never used to evaluate for upgrade.

My solution was to append the third and fourth sets of digits together. Since the major and minor build values increment somewhat regularly and we reset to 0 for the third and fourth sets, it is unlikely we will ever exceed the 65,535 values.

So as part of my build process I get our current build version, e.g. 1.0.1.101. I created a powershell script action for our build process that strips the third and fourth values to a list and then concatenate the third and fourth together. The value now looks like: 1.0.1101. I pass this value into our build for the -y parameter if you are using the standalone build command line option.

This gives us the behavior we want and it closely relates to the file version given to our binaries at build time. This way the installer and the file versions are synchronized.

I don't know if this will work for your work flow or not, but it satisfied my product managers.
NOTE: I also keep a sentinel file on the build machine that contains the current build version. I simply read the version from that, however, you could also read one of your compiled binaries and get the file version from that as well.

[Shobha_Dashotta]

Thanks Dan for the response. That won't work for our requirement

I have a working upgrade now. All the upgrade paths are now supported. After spending days of efforts on this, I realized that when I added the entry in the upgrade table a custom action ( rather a IS standard action) ISSETALLUSERS got added . I removed that custom action. Also, not sure if it helped but the ism has a table called " Installshield", the entry there for "OnUpgrade" was 0. I made it 2 since 2 is the value for an UpgradeFrom property.

With these two changes in place, I was able to also upgrade from 1.0.1.x to 1.0.1.y.

Regards
Shobha