Major Upgrade - .exe file not reinstalled

Question

I have a .msi file created by a program called MSICREATE and doctored using orca as follows...

InstallExecuteSequence Table

* added FindRelatedProducts with sequence 410
* added RemoveExistingProducts with sequence 1450

InstallUISequence Table

* added FindRelatedProducts with sequence 200

PropertyTable

* added RemovePreviousVersions TRUE
* added SECURECUSTOMPROPERTIES SOLARUPGRADE
* had a existing UpgradeCode with guid created by MSICREATE
* had a existing ProductVersion 12.2.12.0 created my MSICREATE

Added a Upgrade Table

* UpgradeCode same value as Upgrade in Property Table
* VersionMin null
* VersionMax 99.12.31
* Attributes 1
* ActionProperty SOLARUPGRADE (same value as SECURECUSTOMPROPERTIES in Property Table)

I also assigned a new PackageCode and a new ProductCode so the new msi had different values of PackageCode, ProductCode, and ProductVersion than the previously installed product.

When I run this msi with the product previously installed, the old product is deleted, a new program files directory created and all the files except the .exe reinstalled from the new .msi. A repair will cause the .exe to be created. If the new msi is installed AFTER removing the old product (using control panel add/remove programs), all files including the .exe are installed.

The msiexec log file is mywebspace.wisc.edu/mdorl/msilog/log3.log

The .msi is mywebspace.wisc.edu/mdorl/msilog/sbl_Major_Upgrade.msi

The only things that looks weird to me are the following lines from the log. The first, second, and fourth are files that do get installed, the third is the .exe file that does not get installed. NOTE THE NULL ACTION ON THIS ENTRY.

Action start 8:04:41: InstallValidate.
MSI (s) (18:F4) [08:04:41:671]: Feature: _MainFeature; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _24A30964F6B6462282E161248AF15827; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _7B95B32E33EB4F699B44D53CA5BC22B5; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _2FBD153583AF40C09EB9920149F7C7B7; Installed: Absent;   Request: Local;   Action: Null
MSI (s) (18:F4) [08:04:41:671]: Component: _38A400D7DB76479CA0EC6D643D5793CD; Installed: Absent;   Request: Local;   Action: Local

Answer 1

The entries in the file table ALL have no version. Why are the non .exe files treated differently and reinstalled?

I suppose the other files have their version increased. Windows Installer should apply the versioning rules on all the files from the package.

So this means it's impossible for a user to install an older version of a product using a major upgrade msi?

I don't see a solution if you want to keep the version smaller in the new package. Except of course, custom actions.

And what constitutes a legal version? In one place I see 255.255.65535 and in another I see 65535.65535.65535.65535

Both of them are correct version numbers. The latter value is usually set to a file to make sure it replaces any other existing file from the machine, i.e. its the highest version number allowed by the OS. http://msdn.microsoft.com/en-us/library/windows/desktop/aa368596(v=vs.85).aspx

Answer 2

If you look in the log at the line 603 you will find the following:

MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {ADC6C3E9-A0CF-4AFC-9998-7B9449C8EA10} since another client exists MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {F74907E7-607E-49D1-B613-D63A36ADB020} since another client exists MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {B1FE4023-E176-42BC-92C3-15B8E50CFBB0} since another client exists MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {E6F5DF5D-3460-4B44-8743-48787E68A2C1} since another client exists

This can happen if the same components are shared between multiple packages installed on the same machine. Windows Installer keeps a refcount for the components and does allow removing them until all the applications that use them are removed.

If you encounter this on your test/development machine I recommend testing on a clean VM, to ensure no other previous tests affect this one.

Also, if you know you have used the same components in packages for other applications please edit them, making sure each component has an unique GUID for each package.

Answer 3

A keyfile is used by Windows Installer to detect the component, along with its GUID, here are more details: http://msdn.microsoft.com/en-us/library/windows/desktop/aa370561(v=vs.85).aspx

As you suspected, Windows Installer is also checking the file version, which I assumed you correctly incremented in the new version. Here are the rules followed by it: http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx

You need to have the version column from the File table for the EXE set to a higher value then of the one already existent on the machine, otherwise Windows Installer will decide its better to keep the old one, because it has a higher version.

Answer 4

For the sake of putting some closure to this item, here's what I've discovered and what I did to fix things.

1) I'm still fuzzy on the meaning of versioned/unversioned file. I guess all .exe files ar versioned. I suppose this means that such files need corresponding versions in the File table.

2) I now understand the file table version need have no connection to the ProductVersion.

3) I have been using illegal ProductVersion Eg. 2012.02.16. I switched to using something like 12.2.16.

4) I set the .exe VS_VERSION_INFO FILEVERSION in Visual Studio and added the same value to File table Version field.

Now, all files are replaced when I do a major upgrade.