Msiexec REINSTALL=ALL REINSTALLMODE=vamus not rein

问题:

Basically I'm trying to upgrade my application, and to my understanding the following should unconditionally reinstall all components: msiexec /i myapp.msi REINSTALL=ALL REINSTALLMODE=vamus

In the verbose log however I see: MSI (s) (A0:60) [15:40:10:948]: Component: A; Installed: Local; Request: Null; Action: Null

MSI (s) (A0:60) [15:40:10:948]: Component: B; Installed: Local; Request: Null; Action: Null

MSI (s) (A0:60) [15:40:10:948]: Component: C; Installed: Local; Request: Null; Action: Null

MSI (s) (A0:60) [15:40:10:948]: Component: D; Installed: Local; Request: Null; Action: Null

Etc for every component. If I delete or rename a file from the destination folder it will properly install the new version, however if the file exists in the location it'll ignore it instead of replacing it with the copy in the current msi file.

Does anyone have any insight on what could be going wrong?

Edit: The installer was created in WiX. Product ID and UpgradeCode remain the same, while PackageID is set to * so a new one should be generated for each build, so that should be correct as far as I know

回答1:

This is kinda tricky to get right, I had the same problem. To make update installation work the update package has to contain ALL of the components from the original package. This means that you can't delete a component ever. You can remove files from a component, even all of them, but you are not allowed to remove a component. Otherwise the update installation won't actually do anything when doing a patch or a minor update. The ComponentIDs are stored in the Windows registry and the Windows Installer Service uses them to check if a Component is installed on the system or not.

What to do if you have deleted components? You could try to add them back, but they have the same package IDs, and this is the hard or even the impossible part.

If it still doesn't work you have to opt for a new installation and have to figure it out yourself what has to be updated.

Alternatively you could do a major update which does a deinstallation followed by an installation. The Windows Installer does not care about the Feature-Componenent structure this way.

回答2:

Have you updated the version number and configured the upgrade?

回答3:

Windows installer will actively prevent downgrading binaries to the degree where it is difficult to accomplished even when using "sheer force" as you do with REINSTALLMODE=amus. This is part of the Microsoft strategy to prevent the "DLL hell" that existed in the early days of Windows. In those days it was possible to overwrite system DLL files with older versions and hence break things left, right and everywhere. Windows Installer has several layers of protection to prevent downgrading binaries.

In cases where you need to be able to downgrade files like you mention, the only approach that really works is to use major upgrades. Major upgrades are not really upgrades as much as uninstall and reinstall of the product in question. This allows you to avoid many of the complexities involved in getting MSI minor upgrades to work properly.

There are complexities even with major upgrades with regards to downgrading. You have to sequence the uninstall of the existing product early in the InstallExecuteSequence in order for the old product to be gone from the system before Windows Installer analyzes the system too much during file costing. This operation compares the system state with the files in the MSI and determines what files need (re)install. If version logic indicates that the file in the MSI is a downgrade the end result could be that the file on disk is removed and the older file isn't installed at all. It could be necessary to actually remove the file early from disk with a custom action to make downgrading reliable, or use an installation folder where the target destination folder's absolute path is different between releases. This will fool the MSI "file costing" to not see the file installed in the same place:

%ProgramFiles%\My Company\My Product\1 %ProgramFiles%\My Company\My Product\1.1

I don't like this "moving target" installation folder - it is not the way an MSI file should install in my opinion, but it could solve your problem.

回答4:

I had the same problem.

What worked for me was removing completely the REINSTALL=ALL REINSTALLMODE=vamus

I think that the main problem was the v option in REINSTALL mode, as according to the documentation on the link below, "Do not use the v reinstall option code for the first installation of an application or feature", and I was installing a new version of my product on top of the old one.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa371182(v=vs.85).aspx