The old version of the setup was created with InstallScope="PerMachine".
The new version is intended to have InstallScope="PerUser"; it also needs to use the same registry keys as the old version creates.
The problem is that whatever values are stored under these registry keys during the upgrade will be overwritten at the end with the initial values stored by the old version. Even deleting these keys manually before the installation will make them reappear (with the wrong values) after the installation process.
I have tried creating a custom action and specifically delete these keys, but the result is the same.
How can I ensure that the old version does not interfere with the installation process of the new version allowing to delete the old Registry Keys and re-create them?
What I found to be working:
Performing a REPAIR immediately after installing the new version will yield the correct results!
Uninstalling the old version manually before installing the new one will not remove the keys, but will allow to overwrite them with the correct values.
You should define what kind of upgrade you are doing, and if it's a major upgrade then where is it sequenced in your major upgrade element, although...
Probably the main issue is that cross context major upgrades aren't supported by Windows Installer, so if you are doing a major upgrade you will end up with both products installed. That's not an upgrade, that's most likely just a collision. So assuming that you want only one of them to be installed at the end of all this, you will need to uninstall the older per-machine installation and then install the per-user. As to why the uninstall of the per-machine product doesn't remove the registry keys, there are many possible reasons, such as they were created by the app not the MSI, or the component was marked permanent, or the component has another client product on the system - a log of the uninstall might show what's going on.
I have to add this as an answer, too long as a comment. I will "evolve" it once you provide more information:
Why do you want to switch to per-user installation? In the MSI world this is not an ideal way to deploy. An application is usable per-user even if installed per machine. With a per-machine install you simply add the ability to write shared settings that should not be overridden by a user. And your application is easier to upgrade, uninstall, patch and manage overall.
Here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):
Having an issue with WIX upgrade
Understanding “Per-User” or “Per-Machine” context for application Setup packages
Are you deploying HKCU or HKLM keys? I would not recommend writing any HKCU values from your setup, they should be written by the application itself. A setup is for writing to HKLM and other places that require "elevated rights". It should never be used to write user preferences. There will be interference when you do upgrades (as you have experienced).
Where is the registry data you speak of stored? In a single MSI component or several? Is there anything else in that component that still needs to be installed without the registry keys? If you can, please add your source WiX file so we can see for sure.
I am sure that we can make all these problems go away if you follow our advice precisely. You are facing a very common MSI problem.
Let me attempt a tentative answer without having all the information:
Remove all HKCU registry information from your setup (if you can).
Update your application to write these HKCU values itself, and ideally write to a brand new location in the registry instead of the old one. For example HKCU\Software\MyCompany\MyApp\5 instead of HKCU\Software\MyCompany\MyApp. This "decouples" your old and new state, and you got room to maneuver and clean up things.
Making your application write the HKCU keys is not a hack, but the right thing to do. It will make your application much more robust and generally easier to QA for yourself and your team. You can "wipe the slate clean" during testing and start over without a reinstall - in order to focus on application testing.
Put any remaining HKLM settings in a single WiX component and set a good key path that will never be modified or deleted by the user or any other process. For example: HKLM\Software\MyCompany\MyApp\5\MyAppHKLMKeyPath = 1
If you discover that you have to override a value for each user (in other words change something for every user in HKCU), you can do this with this approach which combines what the setup does with the application itself: http://forum.installsite.net/index.php?showtopic=21552 (if this is important, please read the whole, linked thread).
Related
In my wix installer I want to add registry keys to the following key path
HKEY_CURRENT_USER\Software\Microsoft\Edge\NativeMessagingHosts
This path exists if the user has installed Microsoft Edge Chromium.
I can conditionally add keys if this path exists, however how am I supposed to deal with the case where after the user installs my application they install Edge Chromium?
Will there be any issue if my installer simply creates this path first?
I think this answer can only be resolved by testing the interaction with Chromium Edge. Create a VM and snapshot it before and after installing Chromium Edge. Test your installer using both snapshots and see if the behavior is the same.
Generally I would block the installation of your product if it requires another product. Even if the order of operations don't matter there is still the scenario where your product is installed and Edge isn't. This might not be a big deal if it's an optional feature but if it's the core feature of your product then someone might think your application is broken. This is why we would block the install and say it require another product.
How do I avoid triggering self-repair from my WiX generated MSI package?
This is a Q/A-style question with an answer that just list a few things not to do in your MSI file to avoid the most common causes of repeating self-repair.
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
General WiX / MSI Advice: This self-repair piece was
split from the original answer on general MSI problems:
How do I avoid common design flaws in my WiX / MSI deployment solution?
Short Summary
I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file. Other deployment specialists, please extend the "pitfall list" below.
The earlier answers I wrote turned out to be developer relevant, but not developer friendly:
How can I determine what causes repeated Windows Installer self-repair? - Focuses on understanding the self-repair problem in general. Setup developer / application packager focus.
What do I do when launching an application triggers repeating, endless Windows Installer self-repair? - Provides a checklist for solving self-repair scenarios. "How to fix focus" - rather than just understanding. For developers, sysadmins, application packagers and end users. How to handle bad MSI packages in general - from any vendor or source, not just your own.
I think there is time for yet another perspective on self-repair. Now I can finally write what I intended all along: the developer's view of self-repair - some of the pitfalls to avoid for developers who do their own setup development work - often using the WiX framework. Just a short, concrete list of things not to do in your MSI package.
MSI / WiX design pitfalls causing self-repair issues
This is a rough first-draft. These bullet points will be fleshed out when time allows.
You mess up the installation of shared runtimes. You don't use merge modules to deploy globally registered, and/or shared runtime files. Rather you install your own copies of the files and register them system-wide. This is particularly bad for COM files, but applies also to other types of files. Conflicting applications will try to put their state back, and "self-repair fighting" results on every alternate application launch.
You run into the empty folder self-repair peculiarity. You create an empty component with a directory key path without adding a CreateFolder entry. This causes an endless loop where MSI removes the folder and then triggers self-repair to put it back. There might be protection in WiX against this at this point.
Incorrect component reference counting. You create a suite of packages yourself that install a file with the same name to the same location on disk from different MSI setups using different component GUIDs. This will most likely trigger self-repair as the packages "fight" to put its version of the file in place. There are several "fixes" for this such as designing a merge module, using a WiX include file, installing the file without reference counting (blank component guid) - (more details will be added soon).
Erroneous per-user file installation. You install files to the user-profile and set a file key path instead of a registry key path in HKCU (required by MSI design guidelines). This frequently cause regular users to experience repeating self-repair that never succeeds due to missing disk permissions. The key files are not "seen" by the regular user because there is no read permission where the key file resides (another user's user-profile). Here is a color illustration. And in addition to a link, in image form as well:
Erroneous disk / registry custom permissioning. This problem is different, but similar to the previous issue. You apply custom file, folder and registry permissions during installation that removes read access to installation locations for regular users. Regular users will see repeating self-repair that never succeeds. This can happen to "per machine" file locations as well, not just user-profile paths (like the previous issue). I hear rumors that some have seen this in particular for write protected ini files as well.
You leave ref-counting enabled for temp files. For some crazy reason you decide to install a file to the tmp folder or another folder that might be cleaned up at any point. Perhaps you intend to run the file from a custom action or something. In either case you install it via a component with a component guid and a key path set, and when the file is "cleaned" from disk, your MSI file will try to put it back. This repeats every time the file is "cleaned". Since the install location is likely a per-user location, other users might not "see" the file from their login, and they experience immediate, repeating self-repair whereas you only see it when the file is "cleaned".
Malware - real and false positives. You install an unusual binary without running it through a basic virus / malware screening. It is as important to check for actual malware as it is to check for false positives (one malware scanning service to use is http://www.virustotal.com - almost 70 different scanners - pay special attention to the major vendors - obviously). So you ignore the malware check, and after deployment your product suffers false positives from several anti-virus vendors and self-repair will run in vain trying to put back the file only to have it "quarantined" again. Your customers blame you (funny how a false positive can be harder to get rid of than real malware?). The result is of course equally bad if you actually install a real virus or malware instead. The result is exactly the same - self-repair keeps running in vain. On the other hand, if the binary was infected after installation, then self-repair should serve its purpose and run once to put the clean file back in place. The major problem is that fixing a false positive is actually harder than dealing with malware (malware is of course worse for the customer if it causes data loss, but it is understood that this is out of your hands as software provider). With malware you simply tell your client to rebuild their PCs and reinstall your software, but with a false-positive you need to do something to whitelist your binary - often with several security software vendors. How do you deal with this process? As malware seems to become worse and worse and security is attempted tightened in any way possible, false positives are likely to become a major deployment problem - even more so than now. A lot of time can be wasted trying to get your binary whitelisted. And the obvious, but let's just say it out loud: don't brave this task on your own as a deployment person - this whitelisting is a huge task that requires management involvement. The problem affects everything for a software vendor: sales, development, marketing and support. As security software become more advanced and "smart" - they may start to quarantine the whole cached MSI on the system that is found in %SystemRoot%\Installer (used for maintenance installs, repair and uninstall). When this happens no self-repair will be possible - and also no uninstall (!) - unless you have access to the exact, original MSI that was used to install with. In these cases I suppose you could try some of the options listed here to get your MSI with malware or false-positives uninstalled: Why does MSI require the original .msi file to proceed with an uninstall? or section 12 here: Uninstalling an MSI file from the command line without using msiexec.
You install desktop files likely to be deleted by the user. This is a "fringe case" requiring that you have also erroneously set the key path for the installing component to a disk key path (rather than the correct HKCU path). Most of the time you put shortcuts on the desktop, and this is fine. However, if you install a data file of some sort that the user then deletes, you could see it put back by self repair when your application is launched via an advertised shortcut, or even if a advertised COM object is instantiated or a particular file type is launched.
You install advertised shortcuts to the "Startup" folder. Don't install advertised shortcuts to the "Startup" folder. It can trigger self-repair to run on every system startup without any user interaction taking place at all. Deleting the shortcut has been reported to also trigger self-repair. This is something I have never actually seen, but it makes sense.
You use a HKCU key path (or HKLM for that matter) that your application changes. Any setting you write from your MSI to the registry should generally not be modified, or worse, deleted by your application's operation. Self-repair will likely result. Only write data that the application just reads. Your application itself should always populate all default settings to HKCU, and your setup should never interfere with them. The same goes for userprofile files. They should be copied for each user from a per-machine template location. The overall moral of the story: deploy only per-machine files and settings (HKLM). Everything else should be initialized by the application: Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?.
Your setup writes to registry keys that are periodically overwritten by group policy. I believe I first saw this problem in relation to some IE proxy settings keys in HKCU being set using an MSI. Using an MSI to just set a few registry keys is always a bad idea for a lot of reasons. Please see this serverfault.com answer for a list of several problems: MSI package for reg deployment (recommended quick read, though it is most relevant for system administrators, but important to know about for developers). I am having trouble reproducing this problem since self-repair is triggered when key paths are missing (generally not just changed or modified). Perhaps group policy actually removed the HKCU values that were added by the MSI? We did see the problem, so this is probably what happened. The overall message: never use an MSI to just set a few registry keys, particularly if they are in HKCU. Use group policy, logon scripts, VB Scripts, PowerShell or other, more reliable measures such as having applications do it on launch (once per user).
You register a particular file / MIME association or command verb in your MSI file. Most self-repair seems to be triggered by COM registry interference between products that triggers self-repair on COM object instantiation, or the invocation of an advertised shortcut. However, you can also trigger self-repair via file / MIME associations and command verbs. In particular file associations could be registered by other applications / MSI files on the system, and this could trigger very persistent self-repair as each application tries to "steal back" the file association. Use these features sparingly in your MSI - and make sure the file associations you register really are unique. Never set a "common" file association in your MSI setup (for example jpg).
The same MSI is installed twice (or more) by mistake. This sounds strange, but it is possible in several ways actually. Self-repair might not be your biggest problem if this happens, you will see other problems too:
You forget to generate a new package GUID for your rebuilt MSI. Windows Installer then treats the two different MSI files as the same file "by definition". I believe I have seen self-repair in these cases, but you will be facing a plethora of other problems as well, all equally weird. Always auto-generate the package GUID. There is no reason for any two MSI files to have the same package GUID (unless you are testing something incredibly obscure in the Windows Installer Engine). While fully aware of the problem of duplicate GUIDs, it still happened to me many years ago using Installshield during some very hectic development. I still wonder how it actually happened - but it did. Perhaps it was an unknown bug in the tool?
A failed major upgrade can leave two versions of your setup installed at the same time. You see two entries in add/remove programs. Self-repair problems are possible in these cases, but so are a plethora of other problems. In my experience this problem is serious, but not as bad as using the same package GUID for two MSI files (previous bullet point).
I am sure there are several other ways the same product can end up being installed multiple times. Perhaps failed multi-instance transforms can cause the problem as well? I dislike that particular concept so I haven't really tried.
Some general "runner-up" self-repair related issues:
Run validation on your MSI and several of the above issues will be flagged and easily eliminated.
Never run MsiZap.exe on your developer box or any machine that you can't easily revert. In fact don't use this "tool" at all. You will often see self-repair problems when deploying on top of the "dirty state" created by the MsiZap.exe's nuking of the MSI database.
If you need to install COM shell extensions, make sure to test thoroughly when using Windows Explorer and switch between different view modes to check if self-repair kicks in. A COM object like this is essentially in continuous use, and self-repair is hence very likely (certain) if any settings are interfered with.
If you put an advertised shortcut in a feature by itself it should almost never trigger a self-repair. Key path checking is done for the feature the shortcut is in and for all its parent features (last time I checked ;-) - which was years ago).
Self-repair related answers (links for safekeeping):
What could be causing MsiInstaller to continuously reconfigure applications (EventID 1035)?
How can I determine what causes repeated Windows Installer self-repair?
Serverfault.com: How can I determine what causes repeated Windows Installer self-repair?
MSI self-repair triggered for the non-admin user when Tabctl32 was installed via merge module
Diagnosing self-healing MSI
why does windows installer start up everytime i start up visual basic 6
I used a wix generated msi file to install a software. Installing the software works fine, but sometimes there are some problems during uninstall.
All the files in "Programm Files" are removed as expected but after the uninstall, some data still remains on the system:
the app entry in "Programs and Features"
the installer in "C:\Windows\Installer\"
(and some registry entries which point to the two things above)
The problem is: as long as those data is on the system, it's not possible to reinstall the same version of the software. The installer shows the "Repair / Remove" action. None of them are working anymore.
But why does the installer not remove those files/entries?
What could be the problem?
Just some notes: when performing a MajorUpgrade, the new installer removes all the old entries. But this is not a solution.
Ans yes, all those registry entries and files can be removed by hand. After that a reinstall is possbile, but this is also no solution for the users.
This doesn't make much sense, primarily because installs and uninstalls are complete transactions, so that if an uninstall fails it will roll back and the entire product will still be there. It won't be a partial uninstall where some things stay and others are removed. Some things to look at are:
Do a log of the uninstall with msiexec /x {productcode} /l*vx [path to log file] to see if something shows there, for example if it finished successfully.
The \Windows\installer directory is full of msp, msi, mst files, so it's not clear what you mean about "the installer" being there because lots of cached installer files are there. Yours might be there too, I agree, if there is an entry in Programs and Features. That just means that there is still that product installed.
It's not clear why you mention upgrades, or what the entire scenario is. However you would get to your current situation if you had two installs where one was installed over the other incorrectly. Uninstalling one could remove all the files but leave a product behind.
Your system may no longer be clean if the same ProductCode has been used for multiple installs and testing, or you've attempted to clean things up with a tool like MsiZap. Start with a clean virtual machine every time, and see if you get the same issue. If this is happening on one test machine that might be scrambled due to repeated testing, then it could help to give your setup a new ProductCode and a new UpgradeCode.
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
This is similar to the question asked here: How do I fix the upgrade logic of a wix setup after changing InstallScope to "perMachine"
Only in our case, the old version is "perMachine" and the new version is "perUser".
I understand why you would not want a perUser installation to mess with a program that might be shared among several users. But we need to go down this path.
Currently, we are detecting versions of the old program by digging around in the registry and refusing to install unless they uninstall the old version first. It isn't real user friendly.
Are there any better techniques?
It can't. Major Upgrades can't switch context and even if you wrote a setup.exe bootstrapper to clean up before the installation it would have to be run for each user profile that installed the product.
I would never change to a per-user setup, I would rather go from per-user to per-machine for an awful lot of reasons. Why do you need per-user?
You might have a look at a description I wrote up on how to migrate to per-machine from per-user using Installshield. Going the other way should be possible too - but not recommended in my opinion: https://stackoverflow.com/a/12291807/129130
UPDATE:
Since this was down-voted, here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):
Having an issue with WIX upgrade
Understanding “Per-User” or “Per-Machine” context for application Setup packages