I tried REINSTALLMODE=amus option but it didn't work showing error message Another version of this product is already installed....
If I give INSTALLMODE=vomus option it works well. But, some files are not overwritten, not updated. Maybe it seems to be a file version related problem. Is there really no way to force WI to overwrite its files except doing major upgrade?
Take a look at the MSDN topic REINSTALLMODE property. The "v" is needed by the minor upgrade, the "o" tells it to only overwrite older files and the "a" tells it to reinstall all files regardless of hash or version.
So REINSTALLMODE=vamus should be what you need. However, if the files in the installer were properly versioned this shouldn't be a problem in the first place.
Related
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).
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.
We want to be able to patch our product in the future by producting an ".msp". A particular exe in the .msi is missing version information.
If we create an .msp in the future, will we have problems upgrading that .exe?
I want to know whether we need to add the version information and rebuild the .msi or whether we can avoid it so we don't have to repeat our release process for the .msi.
This post: http://blogs.msdn.com/b/astebner/archive/2005/08/30/458295.aspx
explains that a versioned file will always replace an unversioned one. So, as long as the any updated version of this exe is given version information before it gets put in a .msp, then it should upgrade ok.
We have a product that we install using WiX, and we have done some re-branding, and I would like to change some things in installation paths and file names.
So, when I make a new version of our installation, the folder with old name remains in Start menu, for example. Also, if I rename a file, the old versions are not deleted, either.
I would like to know what would be the best way of installing files with new names over previous versions of installation.
It sounds like you're doing a major upgrade with a late scheduling of RemoveExistingProducts. When you do that, you have to strictly follow the component rules. My blog post on upgrades covers ways of avoiding that, such as by using an early scheduling of RemoveExistingProducts.
I'm trying to create patches using the method from this tutorial. An issue I'm running into is that I can't install a new patch on top of a previous patch.
I can full install Version A,then patch to Version B. After that I can't patch to Version C.
I can full install Version B, then patch to Version C.
Currently we just do full installs with major updates each time which is working fine, but because of the frequency of our (internal) updates the file size and update time is becoming a burden so we're looking to reduce the update time (both downloading and installing) especially when most of the files don't change.
Edit: Another requirement is that at any given time a full install can be done instead of a patch. The solution I came up with setting a static product code made full installs on top (without manually uninstalling) doesn't work.
If you're not doing a major upgrade, but you are changing versions, you're doing a minor upgrade. To be able to install the next version .msi file over an existing installed previous version, you're going to have to set REINSTALL to a list of modified features somewhere (or to ALL if you're lazy and willing to put up with Windows Installer doing extra work). Often setting REINSTALL handled by the bootstrap, but it is possible to set it in the .msi and reset it to empty ({})when the previous versions are not installed (condition Not Installed).
Looks like the issue was that I was previously making all upgrades major upgrades, but that's not supported with patching. Changing to a static product code rather than auto-generate fixed it.
Edit:
Looks like it solved the first problem of Install A Patch B Patch C not working, but now trying to do a full install of D on top doesn't work.