The problem is only solved when both your setups "know" that the component is shared and its registry keys should be left alone.īefore I elaborate this, are these MSI file live? As in published in the wild, or are you still in development? There is an answer here that might help if you take the time to read it thoroughly (I think I recommend this - please give it a once-over):Ĭhange my component GUID in wix? (please do read this answer, see if it still makes sense).Īnd now a further complication: having deployed your old MSI files "in the wild" means that setting a stable component GUID from now on will not necessarily help to sort out the problem since your old MSI being uninstalled as you install your new MSI still thinks it "owns" the registry key when it is being uninstalled - and hence will delete it. ![]() Understanding component reference counting is key to understanding MSI. Once it reaches 0 when the second product is uninstalled, it will be uninstalled (unless it is marked as a permanent component). When one product is uninstalled the reference count will be reduced to 1 and the component will hence not be uninstalled. Once the same component GUID is used in both MSI file, the reference count for it will be 2 when both products are installed. Essentially this would entail putting a single component in a WiX source file that is then included by both setups, something like this (using the preprocessor feature in WiX): How to include wxi file into wxs?. You should also be able to use WiX include files - though I have to admit that I have never taken the time to actually try it. MSI's built-in mechanism to do this is " merge modules" (you can build merge modules with WiX). Effectively this means that the component is registered as a shared component. The solution is generally to use the same component GUID to install the registry keys / file in both setups. The problem is that both your MSI setups think they "own" the file and registry keys in question so they happily remove them on uninstall - this is obviously clear. One I found involves exporting the Registry to a text file and from there filter the results.This is a very common question. HKEY_CURRENT_USER\Software\wxMaxima\Style HKEY_CURRENT_USER\Software\wxMaxima\RecentDocuments ![]() Parameters REG_SZ -X '-dynamic-space-size 1000' To paste a usage: C:\Documents and Settings\User>reg query HKCU\Software\wxMaxima What REG QUERY does is to check the values inside a registry key. In theory you would receive the same results.įrom reading the REG help, no option is available to do what you propose on 1. I suppose you could reinstall the program on a virtual environment and monitor there. If, on the other hand, you did monitor everything, then reversing the changes is trivial (because you know what were they). However, some programs might alter something somewhere on the rest of the registry, and that doesn't have a good rule of thumb. If you deleted the corresponding branch you could in theory delete all keys associated with the program. Most programs add their registry keys in the HKEY_CURRENT_USERS\Software or in HKEY_LOCAL_MACHINE\Software in a dedicated branch (I'm looking at wxMaxima, for instance, located in the first path). Unless you were monitoring / auditing the registry when you installed the program (and assuming the happy scenario the program didn't add registry keys at runtime, if so you would need to monitor the registry from start to finish), the program might have added keys to the registry in non-obvious places. Find all keys, values, and data containing "something".Now, the big problem is your first point. ![]() Like I said in the comment, you can delete registry keys all you want, either using the command prompt, or manually with Regedit.
0 Comments
Leave a Reply. |