Removal of registry keys on uninstall, but not on upgrade

[JHC Software]

I'm trying to do somthing and it doesn't seem to be possible.

I have registry keys that I want to be removed on uninstall (i.e., to keep the user's machine clean and be well-behaved). However, I want these keys to remain untouched during an upgrade (since they contain important settings that will work with upgraded versions).

When I try this, with two .msi packages (one is a higher version so that it will upgrade the lower-versioned one), the upgrade seems to work fine, but the registry keys are removed. I assume this is because I have marked those keys to be removed on uninstall with "delete (if present) at uninstall", and Windows Installer is performing an uninstall/reinstall as part of it's upgrade process.

Is this what you'd expect? If so how can I work around it? I need to be able to let the users do a full uninstall (to wipe things clean in case of problems) but also to do a smooth upgrade without clearing those settings which may be important to the user.

[endeavorbest]

hey frn,

At this point of time I think of only one workaround.

If you know those registries, extract from the lower version msi and add the same keys even in the newer version. Thus even if the old msi remove's reg keys, new msi install them again.

Thanks

[JHC Software]

I'm not sure if I understand your workaround.

I know the keys that are created, but I don't know their values (if I did, I wouldn't need to bother storing them in the registry).

I have a key: [Manufacturer][Product][1], and in that there are values created at run-time. That top-level key is set to be created at install time if absent, and removed on uninstall. Is that what you mean?

The problem seems to be that the "upgrade" always perfoms the uninstall actions.

The only workaround I can think of is to not let the unstaller remove any registry settings and provide an app for users to run to wipe the registry settings if they want a "clean install". But not very elegant.

[endeavorbest]

ok, I understand the values would be changed in the registry compared to older ver of MSI.

Something i think of is, If It is a bunch of reg hive you are concerned with then write two customactions. One to export required reg hive to the temp location. The installsequence of this CA should be before removing the old msi. One more CA to execute that reg file and delete that from the temp location. Installsequence of this should be after install reg keys.

[Cata]

Indeed, the main problem here is that an Update does an Uninstall first, then an Install.

Some work arounds this issue:

1. Use a Patch instead of an Update. This avoids the issue entirely, but it is not always appliable.

2. Modify the application so that the customizable Registry Values are created by it, not by the install. This is the right way to author them anyway.

Actual solutions to the problem:

3.
- Create an uninstall custom action that saves the reg values. Condition the CA with REMOVE="ALL" AND UPGRADINGPRODUCTCODE so it only gets run at upgrades.
- Create an install CA that restores the saved reg values, if they exists. Schedule it after the registry installs.

4. Mark the registry keys component(s) as Permanent. They will not be removed on uninstall. Delete them in a Custom Action conditioned for REMOVE="ALL" AND (NOT UPGRADINGPRODUCTCODE)

The downside for 4. is that the actual components remain registered in WI.

Hope that helps,
Cata

[JHC Software]

Many thanks, Cata, this is very helpful.

> 1....

I don't think this is so useful for this app because the patch would be as large as the original install.

> 2....

Actually, the registry values are created by the application. The installer simply creates the parent key for this. My idea for doing this was so that it could be removed on uninstall. I can certainly stop it creating the key on install, but retain the removal on uninstall, don't know if this avoids the problem or not though, I haven't tried yet.


> 3....

That sounds interesting. I'll have a look at that.

> 4....

This sounds even more interesting.

I'm not sure what you mean by "The downside for 4. is that the actual components remain registered in WI". Do you mean the registry key itself is still "owned" by WI? If the installer only acts to remove the reg entry and not create it, do you think this problem can be avoided? And what problems could this cause if it's still registered?

I'll investigate these possibilities later and post a follow-up.

[JHC Software]

I tried option 4 and this seemed to work. I had to create a small app to which I could pass the reg keys I needed to be deleted, and this works. I wasn't sure if this could be done by some kind of scripting?

Anyway, many thanks again.

[toonetown]

Commenting on a super-old thread...but I found a way to achieve this. In the component properties (under Organization) for my registry key I don't want removed, I set it as "Never Overwrite" and "Do not register this component with Windows Installer". The value "sticks" (it gets written on new installs, but doesn't get removed on upgrades).

I actually think it's the second option ("Do not register this component with Windows Installer") that makes it "stick"...but at least this way, it doesn't trigger the "downside" listed by JHC Software.

It also doesn't get removed on uninstall either...but (at least in my case) I have the parent key set to be uninstalled, so that takes care of it.

[Daniel]

Indeed, the behavior is generated by the "Do not register this component with Windows Installer" option.

Thank you for sharing your thoughts with our community. Certainly this info will be useful for other customers.

All the best,
Daniel