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: Preventing Upgrade from running if PreviousSetupVersion == CurrentSetupVersion
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
‎Oct 24, 2008
09:27 AM
Preventing Upgrade from running if PreviousSetupVersion == CurrentSetupVersion
I have a request to author the current build of our product so that if the user has already installed the current full release that the patch does not run and vice-versa.
However, setup.exe seems to be version ignorant and there is no way to specify do not install if the version is the same. It still informs the user that it is going to perform an upgrade even though it does not need to upgrade.
I do have a prevent downgrade custom action in place but that addresses a different issue.
What is the appropriate method to get this to work as desired? Do I need to author another custom action to determine if the product version is the same? If so then I need to somehow distinguish an upgrade from a repair scenario; so using RESINTALLMODE property would not be an appropriate check.
Is this type of scenario doable? Thanks.
EDIT: BTW, this is IS2008, not IS2009 ... sorry for posting in the wrong forum.
However, setup.exe seems to be version ignorant and there is no way to specify do not install if the version is the same. It still informs the user that it is going to perform an upgrade even though it does not need to upgrade.
I do have a prevent downgrade custom action in place but that addresses a different issue.
What is the appropriate method to get this to work as desired? Do I need to author another custom action to determine if the product version is the same? If so then I need to somehow distinguish an upgrade from a repair scenario; so using RESINTALLMODE property would not be an appropriate check.
Is this type of scenario doable? Thanks.
EDIT: BTW, this is IS2008, not IS2009 ... sorry for posting in the wrong forum.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 27, 2008
09:02 AM
Bump ... any ideas on what I need to do.
Authoring the upgrade table does not work. I just get a message stating that the custom action, FindRelatedProducts, which checks the upgrade table did not need to run. When I checked into this I found that this custom action ONLY runs on first install so I cannot count on the upgrade table for patches.
So it appears that the only way to accommodate this request is to create my own custom action that checks to see if the current ProductVersion is installed.
Authoring the upgrade table does not work. I just get a message stating that the custom action, FindRelatedProducts, which checks the upgrade table did not need to run. When I checked into this I found that this custom action ONLY runs on first install so I cannot count on the upgrade table for patches.
So it appears that the only way to accommodate this request is to create my own custom action that checks to see if the current ProductVersion is installed.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 29, 2008
12:52 PM
You could author a custom action that checks to see if the REINSTALLMODE contains 'v'. If it does then you can safely assume that this behavior is close enough to an upgrade that it's safe to treat it as such. A repair operation should not contain the 'v' parameter, though I recall a bug where it does in one specific case when launched from ARP.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 31, 2008
12:00 AM
@bryanwolf
So that is a bug? Well, it's a big one, and it exists in both XP and Vista.
On XP, it happens when you click the Repair button that is "hidden" in the link "Click here for support information" in ARP, an on Vista it happens when you click the Repair button that is available from the Program and Feature panels -not the one in the Maintenance dialog.
I just don't trust the 'v' anymore.
So that is a bug? Well, it's a big one, and it exists in both XP and Vista.
On XP, it happens when you click the Repair button that is "hidden" in the link "Click here for support information" in ARP, an on Vista it happens when you click the Repair button that is available from the Program and Feature panels -not the one in the Maintenance dialog.
I just don't trust the 'v' anymore.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 04, 2008
09:49 AM
Well, you don't want to launch a repair operation with the 'v' parameter included; it will cause issues.
That said, you cannot 'not' trust the 'v' parameter. You also can realistically work around these bugs. Best thing you could try to do is detect the specific REINSTALLMODE parameters and re-set it to what it's "intended" to be ( pecmus or pocmus I assume ).
That said, you cannot 'not' trust the 'v' parameter. You also can realistically work around these bugs. Best thing you could try to do is detect the specific REINSTALLMODE parameters and re-set it to what it's "intended" to be ( pecmus or pocmus I assume ).