I am using InstallShield 2016, on an InstallShield MSI Project, and trying to create a minor patch package, with an Update executable. Everything works well, but registry values change to their default values upon updating.
I have looked into changing the REINSTALLMODE string, but it may be too restricting for future leveraging of the registry key system. I have also read that the use of AppSearch and RegLocator tables to read the values into msi properties. I don't understand how to use these tables so that is a solution I don't quite get.
What am I missing?
Thank you.
The Essence: I wrote a lot and nothing made that much sense. Let me try to make it short instead:
Don't write registry values that your application might change. Here is what I might do to be better set with application settings management in the future:1)use a custom REINSTALLMODEto not overwrite any registry keys on this update, and then I would2)modify the applicationto copy theHKCUregistry keys to a new location and never touch them from then on by your setup.3)You should alsoupdate your application to be able to write all HKCU keys for your application if they are missing- based on read-only template settings stored in HKLM - or you write them from internal defaults stored in the application.exe.
This way you need no HKCU settings written by your setup at all in the future - and no interference will occur for modified values. There are ways to enforce new values - if you need to (UPDATE October 2021:
link broken, but resurrected from Wayback Machine).
I will leave the below as well.
Real-World: This "overwrite registry settings on upgrade problem" is in my opinion an MSI design anti-pattern. Or, as I like to call it: an MSI Festivus Grievance (must see video for context).
To reliably avoid this problem, I want to propose you consider this option:
Eliminate Deployment Registry Settings: Generally you should not write registry settings from your setup that are ever changed by your application.
HKLM keys: I write only read-only settings in HKLM from the setup, and allow them to be overridden via the msiexec.exe command line. And then I read them back on upgrades using AppSearch or a custom action - or not at all - depending on whatever makes sense for the business logic and use-case.
HKCU keys: I would prefer to remove all HKCU keys from deployment entirely in the newer version and write default registry keys via the application itself - using its launch sequence. This essentially always eliminates a lot of deployment problems. You can even have the application copy settings you have written to a read-only location in the registry to its active "live" hive. For example you copy defaults from a read-only registry section in HKLM.
This is the generic approach I like to use to "shield" my application from deployment interference with regards to per-user data - be it registry keys in HKCU or userprofile based. For some applications this is not possible. For example those that don't have an exe with a launch sequence.
But wait, even if you can use this approach and remove the components hosting the registry entries in your new MSI, the uninstall and reinstall (during a major upgrade - which you need to delete components) of your package would then tear out the registry keys unless you have set them to permanent outright.
I sometimes conclude that I have to leave the old components in and copy the new ones to write to a new registry key OR to different registry value names to hold the new values.
Remember Property Pattern: Though for WiX and not for Installshield, Rob Mensching's "Remember Property Pattern" is a lesson in how to use AppSearch. The concept is the same in Installshield. You read back properties using AppSearch during maintenance and upgrade scenarios - of fresh install for that matter.
Rob nicely illustrates the irony of this "remember pattern" in how it will override any new values you have specified on the msiexec.exe command line, unless you take steps to avoid this problem (or your scenario allows this particular problem to be ignored - which is rarely safe). Please read the article for the whole story.
Installshield: In installshield you define the AppSearch entries in the System Search view. The dialogs here should be largely self-explanatory in that you simply specify what registry keys or entries from settings files should be read into whatever property you specify them to be read into. The dialogs are "wizards" so you just click through them and create an AppSearch.
Note!: A very common annoyance is to forget to refer to the correct registry hive based on bitness (32 vs 64-bit):
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla FirefoxHKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Mozilla\FirefoxThis can cause some genuine and repeated confusion - at least in my world. And it is such a silly problem that we all want to avoid it from ever wasting a minute of our time.
You can implement the custom actions suggested by Rob to avoid the AppSearch from wiping out property values coming in from the command line. Or I suppose you could ignore that if the properties in question should not be set from the command line? I suppose that is possible.
Custom Action Approaches: I don't like these, but I will briefly mention them.
Write Registry Settings With Custom Actions: Some prefer to write registry settings via custom actions outright, because they then can add logic to the custom action to write new values as they please, and otherwise keep msiexec.exe away from the values and never reset them unexpectedly. Not the worst approach logically, but but you also likely become your own worst enemy as you add risk since custom actions are complicated to get right and to condition and sequence well. Custom actions are a leading cause of deployment failure.
Backup / Restore - or "Preserve Values Custom Actions": Rather than writing pin-pointed settings directly using custom actions, some people use custom actions to back up and then to restore registry settings en-masse at the end of the installation. Not a good approach in my view. Very clunky and prone to overwrite errors in its own right. Sequencing and conditioning of such custom actions can also become very complicated.
And there are other approaches.