MSI Upgrade failing to install files

[vjmasin]

Hi,
I used MSI Factory to create my initial installer, and it works great. I now want to provide my customers with an upgrade. I have read everything I can on the subject on the Microsoft and Indigo sites and based on that created a minor upgrade. The only changes I made were to the Product Version, and I increased the version # on one of my exes.

My new installer (which uses a custom bootstrapper even though I didn't change the default lua) runs fine (no errors) and in AddRemovePrograms it reports itself as having been upgraded. However none of my files on disk is replaced with the version in the .msi

I have my registry setup to create a log file for the installer and it reports that setup.exe is calling the msi the way I would expect, with these params:
MSI (c) (B0:84) [16:05:57:743]: Command Line: REINSTALL=ALL REINSTALLMODE=vomus CURRENTDIRECTORY=C:\temp\clx\5.2.1 CLIENTUILEVEL=0 CLIENTPROCESSID=3760

If I look at what it says about my exe in the logfile it just says:
MSI (s) (F8:FC) [16:14:53:833]: Component: CLX2005.exe; Installed: Local; Request: Null; Action: Null

Why didn't it copy my changed file down?
Thanks, Valerie

[Adam]

MSI does a few things when it compares files in a minor upgrade. Version number (of your file) is quite high in the list (date is lower). Did you actually change your exe file? If the exe is the same binary file then it may not update the file.

Adam Kapilik

[vjmasin]

I have confirmed using Orca that the version has changed. That is, in orca, if I click on File on the left, the Version column for my exe has changed. It went from 5.2.0 to 5.2.1.

There are 2 other files in the same component and they didn't change versions. Could that be the cause?
thx

[Lorne]

Which one is the key path for the component? The key path determines whether the entire component will be updated. Only then are the file version rules applied for the individual component items.

Microsoft has a lot of rules that must be followed in order for Windows Installer to work properly; there are many subtle interactions in the way they implemented the component reference counting system.

For example, here are some of the guidelines:

Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies.
Two components must not have the same key path file. This is a consequence of the previous rule. The key path value points to a particular file or folder belonging to the component that the installer uses to detect the component. If two components had the same key path file, the installer would be unable to distinguish which component is installed. Two components however may share a key path folder.
Do not create a version of a component that is incompatible with all previous versions of the component. This rule should be applied across applications, products, product versions, and companies.
Do not create components containing resources that will need to be installed into more than one directory on the user’s system. The installer installs all of the resources in a component into the same directory. It is not possible to install some resources into subdirectories.
Do not include more than one COM server per component. If a component contains a COM server, this must be the key path for the component.
Do not specify more than one file per component as a target for the Start menu or a Desktop shortcut.

See also:

Aaron Stebner: How Windows Installer handles file replacement logic for versioned and unversioned files (http://blogs.msdn.com/astebner/archive/2005/08/30/458295.aspx)

...and:

http://msdn.microsoft.com/en-us/library/aa367835.aspx