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
- :
- One more thing...
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
‎Sep 10, 2008
09:32 AM
Minor upgrade or patching ???'s
I have a version of my product XXXX.02 that I need to update to XXXX.03.
My installation uses Dynamic linking to pull the files in and all of the files are in one of two components under a common feature.
Within one of these components, one of the directory names has changed, several files are added to another directory, and some modifications are made to IIS (through a VBScript CA).
I need to be able to perform a minor upgrade (or a patch) to make the transition from XXXX.02 to XXXX.03 but ran into issues with the patch validation. I can currently perform the upgrade as a Major upgrade that completely un-installs XXXX.02 and forces the XXXX.03 installer to re-run my IIS setup scripts (REMOVE=ALL and REINSTALL=vomus). This is very inefficient.
Is there a better way (as far as preparing for the migration between versions) to setup my installation? What is the most efficient method for setting up my features/components/files and folders when considering that minor upgrades (or patches) will be necessary in the future?
Any advise/links are appreciated.
Thank you,
Joshua Foulk
My installation uses Dynamic linking to pull the files in and all of the files are in one of two components under a common feature.
Within one of these components, one of the directory names has changed, several files are added to another directory, and some modifications are made to IIS (through a VBScript CA).
I need to be able to perform a minor upgrade (or a patch) to make the transition from XXXX.02 to XXXX.03 but ran into issues with the patch validation. I can currently perform the upgrade as a Major upgrade that completely un-installs XXXX.02 and forces the XXXX.03 installer to re-run my IIS setup scripts (REMOVE=ALL and REINSTALL=vomus). This is very inefficient.
Is there a better way (as far as preparing for the migration between versions) to setup my installation? What is the most efficient method for setting up my features/components/files and folders when considering that minor upgrades (or patches) will be necessary in the future?
Any advise/links are appreciated.
Thank you,
Joshua Foulk
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 10, 2008
09:35 AM
I also need to know how I can detect (by setting a property maybe?) when the installation is actually performing an update instead of a new installation as a condition for running a custom action.
I know that the REINSTALLMODE property exists, but it is set to "vomus" in the property table. As such, is it always set to that value regardless of whether or not the installer is performing an upgrade, or is it set to nothing at the beginning of the installation if the installer is performing a new installation?
Thanks,
Joshua Foulk
I know that the REINSTALLMODE property exists, but it is set to "vomus" in the property table. As such, is it always set to that value regardless of whether or not the installer is performing an upgrade, or is it set to nothing at the beginning of the installation if the installer is performing a new installation?
Thanks,
Joshua Foulk
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 10, 2008
01:52 PM
Points 1 and 3 from the following article are usually the minimum requirement to authoring a minor upgrade to work correctly when using dynamic file links:
INFO: Patch Creation Tips for Dynamically Linked Project Files
Point 2 is also advisable if the file sets in the dynamic links could be changing (though if this is the case, a major upgrade should be used instead).
You can obtain a more consistent output from dynamic file links with InstallShield 2009 using "best practice" dynamic links. This will automatically author dynamic components at build time per Windows Installer component rules (the current dynamic link functionality in IS 2008 does not do this).
For the most consistent, reliable, and controllable approach to authoring installations and upgrades, static file links should be used instead of dynamic links.
Note that any changes made to the MSI package that causes the feature/component tree to change (besides adding new components or removing existing features) compared to a previous version will necessitate a major upgrade.
For detecting an upgrade installation at runtime, a condition of "Installed" or "Installed AND REINSTALL" could be used.
INFO: Patch Creation Tips for Dynamically Linked Project Files
Point 2 is also advisable if the file sets in the dynamic links could be changing (though if this is the case, a major upgrade should be used instead).
You can obtain a more consistent output from dynamic file links with InstallShield 2009 using "best practice" dynamic links. This will automatically author dynamic components at build time per Windows Installer component rules (the current dynamic link functionality in IS 2008 does not do this).
For the most consistent, reliable, and controllable approach to authoring installations and upgrades, static file links should be used instead of dynamic links.
Note that any changes made to the MSI package that causes the feature/component tree to change (besides adding new components or removing existing features) compared to a previous version will necessitate a major upgrade.
For detecting an upgrade installation at runtime, a condition of "Installed" or "Installed AND REINSTALL" could be used.
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)