(Windows is lazy and only loads the things it needs.)īut you shouldn't even try that one. What about the other users? It could try to enumerate all users, but their registry keys might not be loaded. (This happens if you started the uninstaller from a non admin account and then entered the credentials of an admin account - the setup is now running under that account, not the first one). If a program is installed per machine (which most are) and multiple users use it, what should the uninstaller do? It could safely remove the user settings of the current account, but the current account might not be your account. While keeping leftovers in LocalMachine is laziness, as pointed out by the other answers, it is not possible to clean the User part. Normally, the setup writes values into LocalMachine, and the running program ONLY writes into CurrentUser (actually, unless the setup messes with the permissions, the running program can't write into LocalMachine.) This approach can solve a lot of hard deployment problems - or prevent them from ever existing.The registry has multiple root nodes, but only two interesting ones: LocalMachine and CurrentUser. With all that being said, I want to ask if these registry settings are in HKCU or in HKLM? It is generally not recommended to write settings to HKCU form MSI setups - you should rather populate HKCU when your application is first launched. To get ahead of myself: if you can change the location of the registry key (For example from HKLM\Software\Company\MyProduct to HKLM\Software\Company\NewProduct - which is usually not possible) and then also set a new component GUID for it, then you should be "de-coupled" from the sins of the past and your new MSI files should share the component properly. 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.
0 Comments
Leave a Reply. |