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: Another Custom Action Condition Question...
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
‎Jan 24, 2011
02:26 PM
Another Custom Action Condition Question...
Hi again,
I have another Custom Action Condition question....
Currently in our install, which is always deployed as a Major Upgrade, I have a custom action that runs an installed .exe conditioned with NOT REMOVE="ALL". This has worked fine for us because I know with the Major Upgrade, all previous versions are removed first so the .exe will always be marked for installation.
On a QA machine, the had a version of the .exe already on their machine (suppoesed to be testing on clean images, but NOT) so the install errored because it wasn't marked for installation. This .exe is one that never changes so there is rarely a version change.
To get around this I simply changed the condition to look at the install state: $ComponentName=3. This got around the QA problem, and will work in the confines of our Major Upgrade.
I'm wondering, for situations like this where .exe versions don't change, if it's not better to use a custom action calling an .exe with a path reference in the Directory table. If I went this route, I would sidestep any potential issues if we decide to push out a Minor Upgrade.
I guess I would need clarification on what the install state would be of my component that is the target of the custom action in a Minor Upgrade scenario. .EXE already in place with version 1.0.0.0. Now we have an update and the Custom Action .EXE still has version 1.0.0.0. Does the install state indicate if it is installed overall or just as part of the running install process?
Is there any Best Practice reference for conditioning Custom Actions?
Any help appreciated!!
I have another Custom Action Condition question....
Currently in our install, which is always deployed as a Major Upgrade, I have a custom action that runs an installed .exe conditioned with NOT REMOVE="ALL". This has worked fine for us because I know with the Major Upgrade, all previous versions are removed first so the .exe will always be marked for installation.
On a QA machine, the had a version of the .exe already on their machine (suppoesed to be testing on clean images, but NOT) so the install errored because it wasn't marked for installation. This .exe is one that never changes so there is rarely a version change.
To get around this I simply changed the condition to look at the install state: $ComponentName=3. This got around the QA problem, and will work in the confines of our Major Upgrade.
I'm wondering, for situations like this where .exe versions don't change, if it's not better to use a custom action calling an .exe with a path reference in the Directory table. If I went this route, I would sidestep any potential issues if we decide to push out a Minor Upgrade.
I guess I would need clarification on what the install state would be of my component that is the target of the custom action in a Minor Upgrade scenario. .EXE already in place with version 1.0.0.0. Now we have an update and the Custom Action .EXE still has version 1.0.0.0. Does the install state indicate if it is installed overall or just as part of the running install process?
Is there any Best Practice reference for conditioning Custom Actions?
Any help appreciated!!
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 25, 2011
09:47 AM
Set the attributes of the .exe component to 128 (never overwrite if keypath exists)?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 25, 2011
09:51 AM
I don't really want to do that because if there is a change, I can't overwirte, correct?
Even if I do change to never overwrite, that still doesn't solve anything with which condition to use. I would have to use a relative path in the directory table if that were the case I'm guessing.
Even if I do change to never overwrite, that still doesn't solve anything with which condition to use. I would have to use a relative path in the directory table if that were the case I'm guessing.