View Full Version : Keeping registry value during upgrade

01-12-2003, 08:41 AM
Hi experts

As I have understood, an upgrade is a deinstallation/installation process. How can I keep registry values during an upgrade?

In setup V1, I have installed some empty registry entries. The application has filled these entries with some values.

I have created an upgrade install project (setup V2), which should replace the old application (V1) with the new one (V2). Everything is fine, except handling the registry.

If I don't define those registry entries in V2, these entrys are not created.
If I define those registry entries in V2, these entries are created, but theire values are not set.

I have to find a way to keep theire values during an upgrade, so after the upgrade, the registry values are still the same as before the upgrade.
(BTW Those values ar set by the customers, so it's not possible to hardcode these values in the setup.)

Thanks in advance

01-13-2003, 02:38 PM
This is a limitation of the Windows Installer. Try the following (since the problems you are having are with registry keys that have no values).

1. Open V2 project in Express
2. Go to Registry View
3. Define the registry entries (empty ones)
4. Right click on the key and select the "Install if absent, uninstall if present" option
5. Build and install on top of V1

Technically this should NOT install this key if it already exists on the target machine.

01-13-2003, 02:52 PM

You can do one of the following depending on which one works best for you.

1. Instead of sending a Major Upgrade (which uninstalls the product and reinstalls the new one), you can either send a patch or a minor upgrade. A minor upgrade will update all files and folders based on certain command line arguments. It will not uninstall the old product, simply run the updated product in repair mode. For more information on Minor Upgrade, please refer to article Q105223 (http://support.installshield.com/kb/view.asp?pcode=CLASS350XEE&articleid=Q105223).


2. In your existing upgrade, create a custom action that makes a copy of the existing registry key made by the end user and stores it in a text file. Then at the end of the setup, launch a custom action that restores this reg key by reading it from the text file. You can create an executable in VB or write a vbscript custom action to do this and launch it via Custom Actions.


01-13-2003, 05:38 PM
Thanks Chandima

Unfortunatly it's not working as you said. In V1 I have defined an empty string registry entry PATH. After installation of V1, manually I have changed the value to "C:\".

Upgrade V2 has an empty string registry entry called PATH. But the setting of the key is marked as "Install if absent, uninstall if present".

After installation of V2, in the registry is an empty string entry PATH.

So this is not working. BTW what means the setting "uninstall if present" ? Before applying V2 there is en entry PATH with the value "C:\" present. So V2 is uninstalling it???

The solution of Neeru seems better to me. Should I launch the first action for saving the registry entries "After Ready to Install Dialog" and launch the second action for restoring the entries "After Setup Complete Success Dialog" ?
Which VBScript commands are useful or needed?

Pijus Chanda

01-14-2003, 11:07 AM
Yes Neeru's idea is indeed the best (and surest) workaround. We need to rename that "Install if absent, uninstall if present" thing. What it actually means is "install if absent, uninstall if present DURING THE UNINSTALL". MY guess is that Windows Installer is getting it confused during the Upgrade.

As for the Custom Actions you can use the following VBScript to read and write from the registry.

Set WshShell = CreateObject("WScript.Shell")
MyKey = WshShell.RegRead("HKCU\Software\ACME\FortuneTeller\PATH")

WshShell.RegWrite "HKLM\Software\ExpressUpgrade\TimeStamp", MyKey

02-08-2003, 08:32 PM

I think I am having the same uninstall/install registry wipe-out problem (I use the "install if absent, uninstall if present [during an uninstall]", most keys get created under a root key by the application itself). I need to be able to redistribute a single *.exe to my users (either a patch or a full new setup.exe) that will update an application to the latest from *any older* version of such.

My understanding of the situation is as follows:

1.) I could create a custom action that makes a copy of the existing registry key and re-applies in on install. That is not feasible for me, since the registry set is quite large - registry will be gone.
2.) I can change the Product Code, keep the Upgrade code, change the Product Version, and use Upgrade Paths. That will give me a full new setup.exe that will upgrade any previous installation, but through uninstall/install - registry will be gone.
3.) I can keep the Product Code, keep the Upgrade code, change Product version, without using Upgrade Paths, and do the Q105223 thing with REINSTALLMODE=voums and REINSTALL=ALL switches to setup.exe. That will keep the registry intact, upgrade any previous version (almost there...), but:

"only the features that were installed originally by the end user when installing the main product will be installed. That is to say that if you add New Features to your package, they will not be installed and neither will the features that were not installed the first time.". Ouch. That was close.

Also, I understand that I would have to have separate setpu.exe file for installing the new product (from scratch - without the REINSTALLMODE=voums and REINSTALL=ALL) and one to upgrade (with REINSTALLMODE=voums and REINSTALL=ALL).

4.) I can keep the Product Code, keep the Upgrade code, change Product version, without using Upgrade Paths, and use Quick Patch (right?). This will do everything I need to get done to existing installations, if I leave it to the intelligence of a user to pick the Patcher instead of Installer. Almost there. But, if I understand correctly, QuickPatch will patch only ONE target version. In other words, I need to distribute separate patches (separate*.exe's) to go from 1.1->2.0, 1.2->2.0, 1.3->2.0 and leave it to he user to pick the right one. Ouch.

Is my understanding correct?

I have the following questions:

1.) Can I use the QuickPatch and ALWAYS specify 1.1 (as in the example above) and the newest version? Will that "roll back" from, say, 1.2 to 1.1, and then patch to 2.0 ? And "roll back" from 1.3 to 1.2 to 1.1 and then patch to 2.0 ? Any other way to do this ? Or is that something that the Developer version only provides?

2.) What is going to happen if I keep the Product Code, keep the Upgrade code, change Product version, without using Upgrade Paths and do NOT specify the REINSTALLMODE=voums and REINSTALL=ALL ? Is the new setup.exe going to be ignored ? I think MSI Help specifies something about "Package Id", and if "Package Id" is new, MSI filename is the same, and there is a new Product Version, a Minor Update would be performed.

3.) If I use the method (3.) above, what happens when the application has never been installed on a machine before, and the "REINSTALLMODE=voums and REINSTALL=ALL" switches are specified in the CmdLine setup.ini file? Does it fail? Or just installs the package as it is?

4.) Any other ways to achieve what I need to get done here ?




02-11-2003, 06:03 PM
How many files and registry entries are you going to patch? If it a small number QuickPatch would be the way to go.

1. A QuickPatch will only contain the files that you are updating. So if you run this patch on a machine that does NOT have your original setup, it will give an error message. You can make QuickPatches of a QuickPatch. So suppose your main setup is verison1.00.0000. You can create a patch that updates it to 2.00.0000 and another Patch to update it to 3.00.0000 (and so on). Suppose you just created the 3.00.0000 patch. By default this will update a Version 1.00.0000 setup and 2.00.0000 setup to Version 3.00.0000. All with the same patch.

2. You are correct about the PackageCode. Since the PackageCode's are different you will get a Windows Installer message saying something like "Another version of this product is installed. Please use ARP to remove it...".

3. If you use the REINSTALLMODE method (this is called a minor upgrade) the setup will fail on a machine that never had it installed before.

4. Windows Installer only allows three way to update your setup.
- Small update or Patch (QuickPatch)
- Minor Upgrade (REINSTALLMODE method)
- Major Upgrade (Upgrade Paths)

Hope this answers your questions.

09-06-2003, 08:07 PM
I found this thread from back in February. Is there still no easy way to run an update that preserves a registry key?

09-08-2003, 08:56 PM

Basically, with Express 4.0 SP1 I keep the Product Code intact, keep the Upgrade Code intact, and only change the Product Version (in project General Settings). I also do NOT specify the REINSTALLMODE=voums and REINSTALL=ALL.

If the the package is not installed on a machine, the setup runs the usual installation. If the package is already installed, InstallShield offers to upgrade an existing installation (performing a Minor Update, I think). A good thing is that all files get upgraded to the new versions correctly, and there is NO uninstall performed (registry values will stay intact, etc.). The bad news is that if you have custom actions associated with the package, some of them might not fire.

Hope this helps...


09-08-2003, 09:16 PM

So, if you only change the Product Version and not the Product Code then an upgrade occurs such that files are replaced but registry values are preserved? Is it necessary to include any Upgrade Paths entries? That sounds like what I want. I will give it a try. Is this behavior documented anywhere?


09-12-2003, 07:38 PM

I have tried to keep the Product Code constant and only change the product version (in General Settings), however this doesn't work. The install immediately says that a version is already installed and that it must be removed via the add/remove control panel first. I have tried various settings in the Upgrade Path with no luck. I am running Express 4.0 SP1.


11-26-2003, 10:37 PM
I finally solved the problem of not being able to preserve registry values during an upgrade by writing a small .exe to take care of it as a Custom Action. I have attached "RegiUtil.exe" for anyone who would like to try it. I have tested it to work on Windows XP,2000,98 and will test it further. However use it at your own risk as with any software there is always potential for unforeseen difficulties.

Here are the key things that I do in an install to preserve one or more registry entries:

(1) In my InstallShield project under General Information I set the appropriate Product Version, Product Code, and Upgrade Code. The first two values must be unique for an install that might upgrade an older installation. Also you must create a corresponding Upgrade Path in the same General Info section.

(2) Under Registry in the install script, I install a default value for each registry entry that I want to preserve. If the installation is fresh, this value will be used. During an upgrade this default value will still be installed, but overwritten by the RegiUtil.exe. Note that this approach ensures that the entry will always be removed during uninstallation because, as far as the installer is concerned, the installer installed the entry.

(3) Under SetUp Files I include RegiUtil.exe.

(4) For each registry entry that I need to preserve I create two Custom Actions, one to preserve the entry (if it exists) and another to restore the entry (if it preexisted). Both actions specify the source "File Exists on Target Computer" and location [SUPPORTDIR]. The command lines for the actions that preserve and restore the entry are below, respectively. I invoke the preserving action "After Initialization" and the restoring action "After Register Product". I also set Wait for Action to "Yes" (although it should work as "no") and ignore Exit Code to "Yes."

RegiUtil.exe "HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany\MyKey" MyValueName "[SUPPORTDIR]" MyValueTempFile.bin PRESERVE

RegiUtil.exe "HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany\MyKey" MyValueName "[SUPPORTDIR]" MyValueTempFile.bin RESTORE

The specific usage is: RegiUtil.exe key value_name temp_directory temp_file preserve|restore [verbose]

You should leave off the VERBOSE option for production but use it if you're having any trouble while testing. Verbose will cause any error to be reported in a console.

Note: Included the "C" source code in the most recent attachment.

12-18-2003, 01:04 PM

I have tried to use the RegiUtil program to save and restore registry entries, but I just seem to not be able to get it to work. Can anyone let me know what I am doing wrong?

As a test, I tried to type in the command line in the MSDOS window just to see if it works. Here is what I have typed in at the MSDOS prompt. Note that C:\Vidcast2 is the folder where I saved the program RegiUtil.exe and is the MSDOS prompt after changing to that directory.

C:VidCast2 RegiUtil.exe “HKEY_CURENT_USER\Software\VB and VBA Program Settings\Vidcast\SerialNumber” SerialNumber “[TEMPDIR]” VidCast.bin PRESERVE

Because [SUPPORTDIR] isn’t one of the choices available in the drop down list box in Install Shield Express 4 as a location, I changed it to [TEMPDIR]. Why isn’t [SUPPORTDIR] listed? Just thought I ask. Was this a mistake or is there a similar setting to use? Even if I use [SUPPORTDIR] it still doesn’t work. I next tried using a hard coded path to my C’s drive root directory:

C:VidCast2 RegiUtil.exe “HKEY_CURENT_USER\Software\VB and VBA Program Settings\Vidcast\SerialNumber” SerialNumber “C:\” VidCast.bin PRESERVE

This also didn’t work.

If I am not mistaken, the value of the key SerialNumber is supposed to be written to a file named VidCast.bin.

I then went into my registry and blanked out the value and then reran the command line with RESTORE and then refreshed my registry. If everything was working, then it should have restored the value. Unfortunately, it did not bring back the value as I expected it to.

What am I doing wrong?

First, can this command line be tested in a MSDOS window as I am trying to do? I just want to see if it is working before trying to add it to my Install Shield Setup.

If it can’t be tested from the MSDOS window, then I can easily test it on the command line in Install Shield, which also doesn’t work. I just need to get the correct command line syntax and parameters.

I think I may have one of the parameters wrong. From my understanding, the parameters are:

1. the registry key = this is the path one sees at the bottom in the status bar when you open the registry using regedit; it is also the folder in the left pane. In my case, I am using HKEY_CURENT_USER\Software\VB and VBA Program Settings\Vidcast\SerialNumber.
2. value_name = the value in the right pane in the registry. In my case, the value name is SerialNumber that holds a string value. As a side node, I want to save this string value. As a test, I put in “Gary Test” for the data value of Serial Number value. Therefore, the value that should be restored is “Gary Test”
3. temp_directory = a temporary directory that will hold a file. I am not sure if this can be a hard coded path like “C:\” or must be a [SUPPORTDIR] which again isn’t listed in the drop down list box, so I selected [TEMPDIR] instead which may have been a mistake. Can anyone clarify this?
4. temp_file = the name of the file that will hold the saved value. The example has an extension of “bin” but I am not sure if it has to be a “bin” file. Can it also be a standard text file? I am also guessing the name of the file can named anything. In my case, I named the file VidCast.bin.
5. (optional) verbose = turns on additional messages. I have left this out.

Anyway, I am not sure what I am doing wrong. Can anyone help? In the meantime, because I am in a crunch for time, I am going to write a small Visual Basic 6 standard exe program that will read from the registry to a text file and then restore the registry key values later. This is the same as what RegiUtil does except I just can’t get it to work.

Thanks for taking the time to read my post. Any help is most appreciated. I am not sure why the registry key values / entries can’t be saved and restored when an upgrade is installed when a previous version exists (which of course the previous version is uninstalled first thus wiping out the registry keys). I appreciate any help.


12-18-2003, 01:39 PM

My guess is that "SerialNumber" is not both your key and value name. Try removing "\SerialNumber" from the first parameter.

RegiUtil.exe "HKEY_CURENT_USER\Software\VB and VBA Program Settings\Vidcast" SerialNumber "[SUPPORTDIR]" VidCast.bin PRESERVE

You can run this from the MSDOS prompt, however you will have to replace [SUPPORTDIR] with a hard-coded path since InstallShield is doing that for you in the installer.

Before [SUPPORTDIR] will be available you must add the RegiUtil.exe to the SetUp Files section of your install script.


12-18-2003, 05:15 PM
Hello again,

I have created 2 custom stand-alone exe files in Visual Basic 6: SaveRegistry and RestoreRegistry which are specific to my application. These programs work great.

In these programs, I manually create a temporary registry file name temp.reg (the extension is reg) to save the keys I need to save and then restore the keys by importing the registry file. Each program works on its own and without any problems.

Now I have a problem.

In a normal case, when you run a setup and if you have an earlier version of a program (or the same version), the old version is uninstalled after setting the upgrade paths and changing the product GUID and product version and keeping the same upgrade code. This is great as well since you want to remove the earlier version before the new version gets installed. The problem is with the registry keys, which as others have pointed out get wiped out when the earlier version gets uninstalled.

My custom program named SaveRegistry is not run before the uninstall but after. This is not what I had expected.

I created 2 custom actions as suggested. The first one is listed below.

Name: SavingRegistryCustom Action
File Location: [SUPPORTDIR]. You have to type this in since it isn’t in drop down combo box.
File Name and Command Line: SAVEREGISTRY.EXE. This is the name of my executable program, which saves certain registry keys. It is a compiled Visual Basic 6 standard exe.
Invoke: After Initialization (before first dialog). This was the suggested setting to use.

Does anyone know how I can force the run of my custom program SaveRegistry.exe to run as a custom action before the uninstall runs?

By the way, I am not familiar with QuickPatch but prefer only having one setup file which is easier to manage. However, if this is the only way to go, let me know. Can a QuickPatch upgrade an existing program as well as install the program if the user never has the program? I don’t think so, but I could be wrong.

Anyway, I got off track. All I would like to do is run my custom action before any previous installed versions of a program gets uninstalled. Can this be done?

To sum up, the problem I am now seeing is that the previous version is uninstalled before my custom action runs. Does anyone know how to solve this? If I can get my SaveRegistry program to run before the program gets uninstalled, that would be ideal. However, it seems to run after a program uninstalls, which isn’t good since I need to save the registry values before uninstalling.

Any help is most appreciated.



P.S. I went with my own custom applications to save and restore registry settings because I just couldn't get the RegiUtil to work properly. I beileve both methods work in a similar manner.

12-18-2003, 05:20 PM

Thanks for the help. You have been just terrific.

I will get back to you about using RegiUtil with a corrected parameter list. Yes, I know it was probably something I mistyped in the command line.

In any case, you may still have the problem in which your Preserve command line will run after a program gets uninstalled which may not be expected. However, this is just a guess. It could be the same problem I am having. How do you force your first custom action such as PreserveRegistryCustomAction to run before the earlier version gets uninstalled?

One other question. If I were to upgrade to Install Shield DevStudio version 9, can that program retain registry keys? If it can then I may just have to upgrade since this isn't working.

Has anyone else had success? Just curious. Thanks so much again and sorry for my long messages. Thanks also in advance for any help.

12-18-2003, 06:04 PM

If you are picking Invoke = "After Initialization (before first dialog)" then that executable runs as soon as the installer starts, well before the "uninstall" takes place. The actual uninstall does not take place until after the user allows your install to begin. InstallShield Support--please correct me if I am wrong about this, but I have not experienced any problem with this and have tested on a number of different environments.

Are you sure that you have placed your executable under the Setup Files, English? I am concerned because you say that you still don't see [SUPPORTDIR] in the file location list, and it did not show up for me either until I added the executable to the Setup Files. If you don't install your executable here then it won't be available to the installer when it needs to run it.

I am not too familiar with Visual Basic .exes, in terms of what external components they depend on, but I would also be concerned that some components needed to run those .exes may not be installed at the time your custom actions need to run.

Install Shield Support has told me that DevStudio 9 will allow you to retain registry keys. I personally have been reluctant to spend the significant extra money on DevStudio just to get that feature, and I have been politicking InstallShield to support retaining registry keys in Express for some time. When they advertise that Express supports "upgrades," to me that inherently includes the ability to retain registry values, however InstallShield apparently doesn't agree with me on that one. I should say that InstallShield support has been very responsive in working with me on all support issues; they're probably one of the best.

12-19-2003, 06:04 PM

Thanks for all your help. You have been very helpful.

Sorry for the length of this message, but I didn’t want to leave anything out. I apologize for any inconvenience.

I still am having some problems. Maybe I have a setting wrong or something. I am just not sure.

And for some strange reason [SUPPPORTDIR] sometimes appear and sometimes doesn’t. For most of the time, it doesn’t and I am not sure why, even after adding a file to the English node in the Setup File(s). I have added the same file again to the DISK1 node in the Setup File(s), but that didn’t help either. By the way, the file should be in the English node and not the DISK1 node as indicated in the message in the next paragraphs. I have Service Pack 1 installed as well; maybe there is a Service Pack 2 that fixes this problem.

Here is what Chandima Rajakaruna says about this issue in a previous post (copied and pasted) which I believe answers this issue about [SUPPORTDIR]:

*** Chandima Rajakaruna’s message ***

I'm afraid SupportDir has to be manually typed in at the moment. However, the reason your custom action is not working is because SupportDir corresponds to the location of the "English" node in Setup Files View. Not the Disk1 Node.

So simply go to the Setup Files View and move your file from the Disk1 node to the "English" node, build and run the install. The Action SHOULD launch.

Chandima Rajakaruna
InstallShield Software Corporation

I went back to using your program RegiUtil and followed along with you recommendation by leaving off “SerialNumber”. You suggested:

Your earlier response:
My guess is that "SerialNumber" is not both your key and value name. Try removing "\SerialNumber" from the first parameter.

RegiUtil.exe "HKEY_CURENT_USER\Software\VB and VBA Program Settings\Vidcast" SerialNumber "[SUPPORTDIR]" VidCast.bin PRESERVE

You can run this from the MSDOS prompt, however you will have to replace [SUPPORTDIR] with a hard-coded path since InstallShield is doing that for you in the installer.


I first wanted to test the RegiUtil in the DOS window just to make sure I had the correct syntax and parameters by leaving off the trailing SerialNumber and using “C:\” as my path enclosed in quotation marks representing a string value.

In the DOS window, I typed in after changing to the directory where I saved the RegiUtil.exe file:

RegiUtil.exe "HKEY_current_USER\Software\VB and VBA Program Settings\VidCast" SerialNumber "C:\" VidCast.bin PRESERVE

See the attached picture with the file named “DOS Window.bmp” for a picture of my current DOS Window.

See attached picture of the registry with the file named “Registry Entries before Preserve.bmp”. I am testing this with the one key named SerialNumber and trying to preserve and then restore its data value using the program RegiuUtil.

I then deleted the key’s data value so that it is blank. See attached picture of the registry with the file named “Registry Entries With Blank Serial Number Key before restoring.bmp”

And then finally in the DOS window, I tried to restore the key’s value. Unfortunately, after running this restore command in the DOS window, it didn’t bring back the value

RegiUtil.exe "HKEY_current_USER\Software\VB and VBA Program Settings\VidCast" SerialNumber "C:\" VidCast.bin RESTORE

As a side note, I did a search for the temporary file VidCast.bin that was suppose to be saved to my root directory “C:\” but it wasn’t there.

In any case, I still wasn’t able to get this to work. Again, I may just have a wrong parameter or syntax error. Not sure which though.

What am I doing wrong?

Anyway, I then went back into Install Shield Express 4. Here is what I have done to try to find the problem. See the attached bitmaps of what the screen shots look like to help you out.

1. Deleted both my custom actions
2. Deleted the 2 setup files. Now there are no setup files.
3. Went back to the “Setup Files” and selected the English Node (so that it is highlighted). Right clicked in the right pane and selected Insert File(s) from the popup menu. Selected RegiUtil in the directory where I saved the file. For a picture, see file named “Screen Shot of Setup File Added.bmp”
4. Created a new custom action named SaveReg with the following properties:
Source Location: File Exists on Target Computer
File Location: [SUPPOPRTDIR]. Still had to type this in because it still does not appear in the list.
File Name and Command Line: RegiUtil.exe "HKEY_CURRENT_USER\SOFTWARE\VB and VBA Program Settings\Vidcast" SerialNumber "[SUPPORTDIR]" VidCast.bin PRESERVE

Invoke: After initialization (before first dialog)
Wait for Action: Yes. In the notes, this can also be set to no.
Run Once: Yes
Execute: During Installation
Ignore Exit Code: Yes
Comments: Left blank
Conditions: No Conditions

For a picture, see the file named “Screen Shot of Custom Action RegiUtil.bmp”.

I then rebuilt and reran the setup that installs my program. And the registry values (specifically my serial number key) weren’t restored which means the RegiUtil didn’t run. My registry values / entry for the serial number was blank. (My original set up writes a blank value for serialnumber key and I have a custom program that writes the value after the setup. When the program gets upgraded say to a new version, I am trying to retain this serial number and then restore it after the setup runs.)

I next went back to my custom programs, which I know, work. I tested my programs by running my SaveRegistry.exe that saves the current keys and values to a temporary registration (extension .reg) file, then deleted the keys out of the registry, and finally ran my RestoreRegistry.exe program, which then brought back the deleted keys. So as standalone programs, I know at least my programs work.

In both of my programs SaveRegistry.exe and RestoreRegistry.exe, I display a message box. For example, when you run the SaveRegistry.exe program, the user sees a message box “Start: SavingRegistry”. At the end of the program, I have another message box “End: Saving Registry”. This tells me when my program is about to run by the popup message boxes. See the attached pictures of what my message boxes look like:

It now just comes to making sure the SaveRegistry program runs before an uninstallation. But this is not the case.

Now here is the thing. When I run my setup file with a custom action to run my own program SaveRegstry.exe with the same custom action properties, it does run but only after the uninstall and it really should run before the uninstall.

Here are the specific things I have done. First, add the SaveRegistry to the English node in the Setup File(s) – right click in the right pane and select insert file(s) from the popup menu (deleted the earlier RegiUtil file since I am not using it.)

Source Location: File Exists on Target Computer
File Location: [SUPPOPRTDIR]. Had to type in it again
File Name and Command Line: SaveRegistry.exe

I have no parameters to my custom program, which is specific to my needs. It saves all my necessary keys to a temporary registration file. In some ways, it is better than having a separate call to RegiUtil for each key that needs to be saved. Just a side note.

Invoke: After initialization (before first dialog)
Wait for Action: Yes. In the notes, this can also be set to no.
Run Once: Yes
Execute: During Installation
Ignore Exit Code: Yes
Comments: Left blank
Conditions: No Conditions

I then rebuilt my project and ran the setup on a machine with the program already installed. Remember, this is upgrading a previous version and attempting to save the registry keys / entries.

The first thing I noticed when I run my setup is that I noticed a message “Preparing to remove”. See the attached picture file named “Uninstalled message.bmp”. Again, this should have occurred after my custom action that runs my program SaveRegistry. If things had been working correctly, I would have seen my message box “Start: SavingRegistry” as an indication that the program is running before this uninstall message. Because I am getting the “Preparing to remove” message, the uninstall is occurring before my custom action.

Still don’t know why.

If I can get this part to work to run my SaveRegistry.exe before the uninstall, then that would be great. Afterwards, all I would have to do then is call another custom action at the end of the setup to restore my registry keys.

Can anyone help? Thanks again for taking the time to read my message. Sorry for the length of my message, but I wanted to be complete.


P. S. The cost of upgrading to DevStudio 9 or purchasing it is more than our companies budget will allow. So, this is not an option I can go with, unless I can’t get this to work. In which case, I may have no choice.

As to your question about Visual Basic’s exe files, they are just normal programs that were created in Visual Basic 6. The compiled program includes all the type library references and objects that are used. After importing a Visual Basic project, Install Shield Express 4 scans the project and includes all the necessary files. In my case with my 2 custom programs SaveRegistry and RestoreRegistry there are no external or non standard components or Active X controls. Besides all the necessary runtime files, and dlls are included with the main setup runs. I am only running these 2 programs and not installing them (hence the reason why they were put in the Start Up file(s).) I would think the VB runtime engine file that runs my main program will also run my custom action programs without any problems. (With my message box testing, it appears that it is running as expected, just not when it should i.e. before an uninstall). Anyway, I hope I haven’t been too much trouble. I know I tend to go overboard, so thanks again for reading.

12-19-2003, 08:46 PM

From your screen shots it appears that you are doing everything right.

When you run the RegiUtil from the command prompt, add the word VERBOSE on the end so that we can see what, if any, errors are occurring. Let's see what is happening here first.

You can also use the VERBOSE feature to see exactly when in the Install script the custom action is being called. In my testing, the PRESERVE action is being run before the Installer even presents the very first Welcome screen--well before the user even has a chance to determine whether to perform the upgrade or not.


12-20-2003, 02:28 PM

Thanks again for all your help. Attached is the error message I received when running the RegiUtil in the DOS window with Verbose switch on.

Do you think it may be a permissions issue? This is just a guess.



12-20-2003, 02:34 PM
Hello again,

I accidentally put in the file name VidCast.bin in quotation marks. After removing them and rerunning the command, the error still occurred. Thanks.

12-20-2003, 04:27 PM

Error 2 means that the registry entry does not exist. Make sure that the path is exactly correct including case.

I looked at the RegiUtil code and it does incorrectly report the KEY name that it is trying to open. However this was just a cosmetic error in the verbose routine, and it actually tries to open the key that you specify. Anyhow, I re-attached the fix to the original message.


12-23-2003, 06:30 PM

I was finally able to get the RegiUtil program to save and restore registry entries when executed in the DOS window command line. I either accidentally left off the key which is named “SerialNumber” as part of the path in the first parameter (it was suggested taking it off) and I made sure I entered the path and key name in its proper case. That may have been the reason. In addition, I also added the verbose argument as suggested.

Here is the corrected string:

regiutil.exe "HKEY_CURRENT_USER\Software\VB and VBA Program Settings\VidCast\SerialNumber" "SerialNumber" [SUPPORTDIR] "VidCast.bin" PRESERVE verbose

Anyway, this is great, but I still have a problem calling this RegiUtil before the program gets uninstalled. If the regiutil is called (with the PRESERVE argument) after the uninstall, then the existing registry entries aren’t saved. Even after setting the invoke to “After initialization (before first dialog)”, the custom action that is calling regiutil with the PRESERVE argument is ran after the program is removed and this isn’t’ good because I then end up saving blank registry key values. The point is to save the registry key values before the program gets uninstalled.

I am now trying to figure out how to get the registry entry to be saved before the uninstall runs. If I can get this to work, then all my problems will be solved. Actually, I would then add another custom action to restore the registry value after product registration.

As an experiment, I also played around with the property Execute and set it to “During Uninstallation”. My reasoning would be that the custom action would run when the program is uninstalled. Remember the uninstall runs automatically before an upgraded or newer version is installed – I am using upgrade paths as a reminder.

Unfortunately, this didn’t work. Anyway, any help is most appreciated. Thanks.

12-23-2003, 11:07 PM

Glad to hear you finally got the RegiUtil to work.

Of course, you will want to remove the verbose option when you go to production.

As far as the timing of the custom action, you will probably have to get InstallShield to help figure that out. When I select "After initialization (before first dialog)”, it definitely runs for me before the uninstall/install process even starts. I am building my install script with Express 4.0 SP1, and I have tested my upgrades with success on Windows 95,98,2000,Me, and XP.

Double check: Under General Information you are keeping the same Upgrade Code for all of the installs, but have a unique Product Code and Product Version for each install. Also make sure you have entered a valid Upgrade Path that corresponds to the Upgrade Code.


12-30-2003, 05:30 PM

I want to thank you again for all your help. I also thank you for your last suggestion since that actually solved my problem.

(The following is a revised message I posted in another thread)

I found my problem. In order for the custom action to run (calling your ReguItil.exe with the PRESERVE argument), you must change the product version and the product GUID. After I did this, everything worked. I am not sure why I had to change these numbers, except to get the upgrade paths to work properly. Anyway, it now works. The invoke argument was correct "After initialization (before the first dialog)".

The funny thing is that I did change the product version and product GUID earlier, but it didn’t help. So, just as a test, I took your suggestion to change the product version and product GUID one more time and it solved the problem.

The "remove" popup box I am guessing comes about when an existing version is being removed (without any change to the product version or product GUID) which in turn doesn't run the initialization. Not sure why, but again after changing the product version and product GUID, everything worked. Thanks.

As a side note, whenever I rebuild or make a change, I now change the product version and product GUID, just to be on the safe side. I know this is probably unnecessary but it will definitely force the custom action the preserves or saves the registry values.

So for now, all my problems are now cleared up. I can preserve and restore registry keys using your program or my own custom made programs. I also had to modify my own serial number to look up in the registry whether or not the serial number was there. If it was blank or missing, then the serial number I created runs as normal; if the key has a value, then I just hide serial number program. This was easier than creating a custom action based on a registry search for the key. I just couldn’t get that to work properly so I found my own workaround.

The only downside I see now is if a user installs the same version on top of an existing version, that he or she gets the program maintenance menu with the 3 options: repair, modify, or uninstalled. If either option repair or modify is selected, my custom actions that save and restore the registry aren’t ran. Only that files are just recopied.

Do you know why the custom actions don’t run in this case? Do you know how to get them to run or do I need to configure something in Install Shield Express 4?

12-30-2003, 05:41 PM
>> whenever I rebuild or make a change, I now change the product version and product GUID <<

I always do that too, even if I only make a minor version change.

>> if a user installs the same version on top of an existing version, that he or she gets the program maintenance menu <<

I don't get that menu, instead I get a dialog saying that the program can't be installed on top of the currently installed version. I am guessing, but maybe this depends on the options that you pick for the Upgrade Paths Min/Max versions and/or Setup Types?

01-29-2004, 01:50 PM
Why are we needing to write custom programs to make this work????? Shouldn't this be fixed in the program?
I really don't want to run extra programs in my install to keep the registry values and then put them back. We ran version 3.5 of express for a long time and didn't run into this problem. It has only been after we installed 5.0 of Express.

And if this is supposed to be a limitation of the MSI then why did it work just fine in 3.5 but not in 5.0? Version 3.5 of the express used MSI to install also.

Basically I just want some keys to remain their until they are updated by a program we run to let the customer update their info. When the original install is done it creates a key but no values. The values are added later after the program is installed. Then when an upgrade is performed it wipes out all the info so it is back to nothing in the key.

I am just confused.


01-29-2004, 04:33 PM

Express claims that it supports "upgrades," which in my opinion implies the ability to retain registry values. But the fact is that it doesn't, so I wrote the utilitiy program to do it.

InstallShield Tech Support is one of the best support teams around, but when it comes to this issue you will get an explanation that you don't want to hear, and the resolution is to buy DevStudio. Hopefully enough Express users will speak up and get the capability back into Express.


09-26-2005, 06:38 AM
hey all,
jst in case someone came looking again, i found a better solution for losing the serial stored value in registry on REPAIR
u can add a system search to that serial num in the target machine registry and store it in a variable like TEMPSERIAL and thn add that TEMPSERIAL in the property manager with its value set to [ISX_SERIALNUM] which is the original value of the serial,
thn on the Customer information dialog on the next button behavior add
an event [TEMPSERIAL] with its argument [ISX_SERIALNUM] and move it up untill its before the EndDialog.
finaly in the registry instead of saving the Serial with value [ISX_SERIALNUM] save it with [TEMPSERIAL]
and thts it :)
struggled alot to get to tht,hope it will help others who need it