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
- :
- Upgrades: Conditional Windows Registry setting during the upgrade
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
Jul 03, 2008
05:06 PM
Upgrades: Conditional Windows Registry setting during the upgrade
Hello,
I've been doing minor upgrades and they've been working well (2.1 to 2.2). However, with this latest minor upgrade (2.3) I've encountered two problems while trying to modify the install to be suited for a both fresh install in Vista and for upgrading earlier versions of the app running in Win2K and WinXP. The same problems occur is upgrading from 2.1 to 2.3 and for 2.2 to 2.3.
BTW, the install is a Basic MSI with a Setup.exe being used for a fresh install and the MSI being used for updating previous installations. Both are created from the same InstallShield project using the Releases View.
I have a Windows Registry entry pointing to a data directory in [CommonAppDataFolder] as the location to store a configuration file during a fresh install. The fresh install works fine.
Now, for an upgrade, I want to keep the original path value in the Windows Registry pointing to [INSTALLDIR], so I moved the Windows Registry setting from ISRegistryComponent and added the registry key and value to the data file specific component. And, I've added a condition to the component "(KEEPPATH=0)' where the 'KEEPPATH' property is defaulted to '0' for a fresh install. Then during the upgrade, I pass "KEEPPATH=1" into MSIEXEC with the idea being to skip this component during the upgrade and preserving the original [INSTALLDIR] value. This does not work, it always sets the Windows Registry key to the new [CommonAppDataFolder] path. I even tried changed the data file component's GUID, same result.
So, I thought I'd create a new component that only dealt with setting the Windows Registry value. When I do this, not only does the path still is not preserved during the update, but even worse, the update fails miserably with most key files not being updated at all. I've never encountered this when adding new components before.
Anyway, I'm stumped at how to preserve the original [INSTALLDIR] value in the Windows Registry and not have a botched upgrade.
Any ideas would be greatly appreciated.
Thank you.
Ken Hartlen
I've been doing minor upgrades and they've been working well (2.1 to 2.2). However, with this latest minor upgrade (2.3) I've encountered two problems while trying to modify the install to be suited for a both fresh install in Vista and for upgrading earlier versions of the app running in Win2K and WinXP. The same problems occur is upgrading from 2.1 to 2.3 and for 2.2 to 2.3.
BTW, the install is a Basic MSI with a Setup.exe being used for a fresh install and the MSI being used for updating previous installations. Both are created from the same InstallShield project using the Releases View.
I have a Windows Registry entry pointing to a data directory in [CommonAppDataFolder] as the location to store a configuration file during a fresh install. The fresh install works fine.
Now, for an upgrade, I want to keep the original path value in the Windows Registry pointing to [INSTALLDIR], so I moved the Windows Registry setting from ISRegistryComponent and added the registry key and value to the data file specific component. And, I've added a condition to the component "(KEEPPATH=0)' where the 'KEEPPATH' property is defaulted to '0' for a fresh install. Then during the upgrade, I pass "KEEPPATH=1" into MSIEXEC with the idea being to skip this component during the upgrade and preserving the original [INSTALLDIR] value. This does not work, it always sets the Windows Registry key to the new [CommonAppDataFolder] path. I even tried changed the data file component's GUID, same result.
So, I thought I'd create a new component that only dealt with setting the Windows Registry value. When I do this, not only does the path still is not preserved during the update, but even worse, the update fails miserably with most key files not being updated at all. I've never encountered this when adding new components before.
Anyway, I'm stumped at how to preserve the original [INSTALLDIR] value in the Windows Registry and not have a botched upgrade.
Any ideas would be greatly appreciated.
Thank you.
Ken Hartlen
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jul 07, 2008
06:08 AM
Ken Hartlen wrote:
Hello,
I've been doing minor upgrades and they've been working well (2.1 to 2.2). However, with this latest minor upgrade (2.3) I've encountered two problems while trying to modify the install to be suited for a both fresh install in Vista and for upgrading earlier versions of the app running in Win2K and WinXP. The same problems occur is upgrading from 2.1 to 2.3 and for 2.2 to 2.3.
BTW, the install is a Basic MSI with a Setup.exe being used for a fresh install and the MSI being used for updating previous installations. Both are created from the same InstallShield project using the Releases View.
I have a Windows Registry entry pointing to a data directory in [CommonAppDataFolder] as the location to store a configuration file during a fresh install. The fresh install works fine.
Now, for an upgrade, I want to keep the original path value in the Windows Registry pointing to [INSTALLDIR], so I moved the Windows Registry setting from ISRegistryComponent and added the registry key and value to the data file specific component. And, I've added a condition to the component "(KEEPPATH=0)' where the 'KEEPPATH' property is defaulted to '0' for a fresh install. Then during the upgrade, I pass "KEEPPATH=1" into MSIEXEC with the idea being to skip this component during the upgrade and preserving the original [INSTALLDIR] value. This does not work, it always sets the Windows Registry key to the new [CommonAppDataFolder] path. I even tried changed the data file component's GUID, same result.
So, I thought I'd create a new component that only dealt with setting the Windows Registry value. When I do this, not only does the path still is not preserved during the update, but even worse, the update fails miserably with most key files not being updated at all. I've never encountered this when adding new components before.
Anyway, I'm stumped at how to preserve the original [INSTALLDIR] value in the Windows Registry and not have a botched upgrade.
Any ideas would be greatly appreciated.
Thank you.
Ken Hartlen
Hi
well have you tried the following Option (took from the Adminstudio Help File)
--------------------------------------------------------------------------
Windows Installer
How do I prevent an old package from installing over a newer version?
Windows Installer upgrade packages can be authored such that major upgrades will not install if the user already has a newer version installed. The following method can only prevent downgrades that might be caused by running a major upgrade package. This method relies upon the FindRelatedProducts action, which only runs during a first-time installation and does not run in maintenance mode (reinstallation.) Because minor upgrades are performed using reinstallation, this method cannot be used to determine whether a minor upgrade package is attempting to downgrade the application. For more information, see Preparing an Application for Future Major Upgrades.
To prevent an old package from installing over a newer version
Enter the UpgradeCode property for the group of related products that may be eligible to receive this upgrade into the UpgradeCode column of the Upgrade table.
Enter the msidbUpgradeAttributesOnlyDetect bit flag in the Attributes column of the Upgrade table.
Enter the version of the upgrade provided by this package into the VersionMin column of the Upgrade table. Leave the VersionMax column blank.
Enter the name of the property that is to be set by the FindRelatedProducts action into the ActionProperty column of the Upgrade table.
Add the SecureCustomProperties property and the property named in the ActionProperty column of the Upgrade table to the Property table.
Add a Custom Action Type 19 after the FindRelatedProducts action in the InstallExecuteSequence table. Include a record in the CustomAction table for this action and enter the text to be displayed in the Target column. The type 19 custom action is built into the installer, so there is no code to write.
Enter the name of the ActionProperty into the Condition column of the record in InstallExecuteSequence table containing the Custom Action Type 19. This conditions the custom action such that it will only be executed when the Upgrade table detects that a newer version is already installed.
For example, a Windows Installer package that upgrades a group of related products to version 3.0 may include the following records in its Upgrade, CustomAction, InstallExecuteSequence, and Property tables. All the related products in the group have the same UpgradeCode, but the installer does not install this upgrade package if a version later than 3.0 is already installed on the computer. In this case, the installer presents an error message and the installation fails. The version 3.0 upgrade package will install over versions 1.0 and 2.0.
Upgrade table
UpgradeCode VersionMin VersionMax Language Attributes Remove ActionProperty
{E7BE6D45-49FF-4701-A17E-BDCC98CE180D} 3.0 msidbUpgradeAttributesOnlyDetect NEWPRODUCTFOUND
{E7BE6D45-49FF-4701-A17E-BDCC98CE180D} 1.0 3.0 msidbUpgradeAttributesVersionMinInclusive UPGRADEFOUND
CustomAction table
Action Type Source Target
CA1 19 A higher upgrade is already installed.
InstallExecuteSequence table
Action Condition Sequence
FindRelatedProducts 200
CA1 NEWPRODUCTFOUND 201
Property table
Property Value
SecureCustomProperties NEWPRODUCTFOUND;UPGRADEFOUND
------------------------------------------------------------------------
maybe this helps also for preserve registry hives