7 replies to this topic

[peterbi]

Hi,

Long time no see (read)

Following is my post to InstallShield community, it's already couple days and seems nobody interested in it or could answer

Generally, I want to prevent the release ones to downgrade on my new releases, but not to completely block the 'downgrade' ability of my product. I have 7 released ones, and have their product codes available, can I use them (do whatever with InstallShield, registry, etc.) to do so?


Thanks,
Peter

Ways to prevent downgrade from certain releases?

--------------------------------------------------------------------------------

Hi,

I think it's doable and not difficult for InstallShiled -

We have a database package that will have some schema change in the coming release (1.8), so we would set (from 1.8) in the package project that all the previous releases (1.1 -- 1.7) are prevented to downgrade on 1.8 and later. But 1.8 (or later) upgrade on previous releases should work though.

My current settings in the package is using 'major upgrade' in Upgrade table so that any up/down grade is working, it looks like -

Upgradecode Versionmin Versionmax Attributes ActionProperty
------------ ---------- ---------- -------- -------------
xxxxxxxxxxx 0.0.0 9.0.0 1025 OLDPRODUCTS



We have the product code of the 7 releases, how can I do it in my current 1.8 package project?


Thanks,
Peter

[Stefan Krueger]

I'm not sure I understand correctly, but preventing downgrade has to be done in the OLD version i.e. the old version needs to detect whether it should be able to replace the newer version or not.

[peterbi]

Stefan,

You are right, the normal 'downgrade' should be set in 'older' releases, in other words, you have to enable or disable the downgrade ability for all releases.

The case I posted is different from that in 1) I want to disable the downgrade only on certain releases, 2) I don't want to disable the downgrade ability to all the future releases.

The package I worked on is a db package, we usually keep the db schema untouched for a relatively long time, but we had to change at this time, and all the old releases shouldn't install on top of this (and thereafter) release due to the change. So what I want to do is to do something in this release so that when an old release is tried to install on top of it, it should reject by posting some error message. But this release should keep 'downgrade' ability, i.e. it should be able to install on top of the release(s) that is released later - until we have schema change(s) again.

I don't know how often this puzzel can happen to other developers, but I can easily think of it in db or db-containing packages. You may say there are other options - totally disable downgrade from the beginning, make it a different product (need to make it incompatible with the previous releases), etc., but either developers or users won't be happy with it. I personally think completely disabling downgrade is a bad practice (I never did so in my packages except I was asked to), don't know how may people outside are using it.

After some research, I find IS consider it as 'undoable', but I have to twick around to make it work - using windows installer of course. If I were IS person, I will put in this feature, which I think is not that difficult, and could make lots people happy.


Thanks,
Peter

[Stefan Krueger]

I stilll think you need to do this in the older version: check for the schema and disallow installation if the existing (installed) schema is newer. You could either check the schema directly in the database or by reading some registry entry (where your setup would store the current schema version).

[peterbi]

Stefan,

Yes we 'SHOULD' have done so in the older versions, and we should have predicted that there could be releases that wouldn't be allowed for downgrade.

But, how can you know that at be beginning of design? You can check schema for db packages, what about non-db packages? So I think the ultimate solution should be in the current build since you (at least I) can't predict all possibilities of all future releases.

Why is it undoable for Windows Installer (actually InstallShield) since it can use UpgradeCode to recognize the incoming product, and ProductCode for a specific version, and if the current installation informs Windows Installer (or IS) that x version of the product should be rejected, WI or IS just do it? It seems to me not a thing too difficult to do.


Thanks,
Peter

[Stefan Krueger]

No installation tool that I know of will ask the existing version whether a new (or older) version is allowed to be installed.

In case of Major Upgrades (i.e. product code changed) with Windows Installer the msi package of the existing (newer) version is called for the uninstall part, and it will see the UPGRADINGPRODUCTCODE property. It could use this information to abort its own uninstall. This could work (never tries this scenario) if the old version's Upgrade table settings are set to exit if the uninstall fails (and not to ignore this case). Also it dpends on the sequence placement of the RemoveExistingProducts action in the old version (see MSI help for details).

I don't know if this approach will work for InstallScript MSI projects.

[peterbi]

Stefan,

Your suggestion still requires the pre-settings at the beginning of the design, which is undoable to the released packages.

All I want to say is that using UpgradeCode and ProductCode, togather with WI, it should be doable for a new release to disallow the installation of a released on top of the new release (downgrade). I can see the needs and goodness to have it. As to whether there are any installation tools doing so, or if IS can do it, is different issue.


Thanks,
Peter

[Stefan Krueger]