MSP file extracts only files that belong to new components

Question

I've created a patch with Advanced Installer by using an old (target image) msi and the new one (upgrade image). Inspecting MSP file I've discovered that it contains both modified and completely new files. The problem is that during the installation it installs only the "added" files. Existing files are ignored. I've already tried MSIEXEC switches like:

• REINSTALL=ALL
• REINSTALLMODE=sumo / aums / omus etc...
• UPGRADE="Yes"
• IS_MINOR_UPGRADE = "1"

..in different order and combinations (i.e. "REINSTALLMODE=aums REINSTALL=ALL"), so don't reply or comment just by telling me to try REINSTALLMODE=omus or something similar.

Answer 1

For some odd reason all the core components (exe, dlls) I wanted to update were set to "Do not register this component with Windows Installer". I suppose this is some kind of project bug, because it's very old and was migrated through different Advanced Installer versions (7, 8 and 9).

Anyway, I was not able to update my application correctly even with a fixed patch. Windows Installer kept on asking me to browse to target image msi file (cached installer of the previous version).

However not all of my customers keep those files (usually this cached files are stored in %APPDATA% folder). So I found a workaround:

1. I've applied "Hash files" option in order to create a MsiFileHash table
2. I've packed my msp patch in a bootstrapper (exe file) that starts it with the TWICE with following command-line parameters:

first time:

"myPatch.msp" /n {150F6CE2-8C12-414B-9377-F087A62E6B67} REINSTALLMODE=c /qb

second time:

"myPatch.msp" /n {150F6CE2-8C12-414B-9377-F087A62E6B67} REINSTALLMODE=dep /qb

REINSTALLMODE=c switch forces file compare algorithm based on hashes, so it doesn't require the original setup sources anymore

REINSTALLMODE=dep restores all the other missing files, files with unknown or different (from target) version

I hope this workaround will be useful to people that use MSI/MSP authoring tools other than Advanced Installer

Answer 2

When creating a patch there is a set of rules that need to be followed, have you checked those? Breaking one of those can lead to unexpected behavior, such as the one you are now encountering.

To check for the rules you can start with a diff between the project files, as they are standard XML ones, and check for their product code, component GUIDs, etc... For example folder synchronization is a common problem encountered when a patch is created, as this changes the component GUIDs.