Level 10

Basic MSI: Major Upgrade problem with file versioning rules of Windows Installer.


We are trying to get a major upgrade to work, but there´s a problem that we are not able to understand.

Basic MSI project:
The RemoveExistingProducts Action is sequenced between 'InstallValidate' and 'InstallInitialize'. After installing the Major Upgrade some of the component key files are missing.
The log file reports (during CostFinalize):
Disallowing installation of component: {BCB1753C-38D3-40A4-9AD5-DA8F6D6F4571} since the same component with higher versioned keyfile exists
for those components (some true type fonts and DLLs). But these files are still the same. No changes were made to them. Timestamps, create and modified date and file version are all the same.
I´ve also created a simple test project using the true type font components only. Same problem occurs on a clean system using this simply test project.
For me it looks like that the file version compare in MSI is a little wacked.

Moving the RemoveExistingProducts Action after the InstallFinalize action would solve the problem but it does not change the outcome of file versioning rules of MSI.

So I really would like to know and understand what´s going wrong here.

Labels (1)
0 Kudos
3 Replies
Level 10

anyone? 🙂
0 Kudos
Level 2

We have run into this same problem. The way we got around this problem was by by moving the RemoveExistingProducts standard Action to before the costInitialize action (we normally set ours to 790 to accomplish this).

A couple things to remember here. One, this is not a recommended practice by Microsoft. Two, if you monkey around with the Major Upgrade Settings, the RemoveExistingProducts action will be defaulted back to where it was.

You should test your install to make sure this solution works for your needs.

Microsoft's recommendations:

Another Macrovision support thread discussing this;

Hope this helps.

0 Kudos
Level 4

I have run into this as well. My major upgrade completes successfully, but there were a handful of fonts and dll's that were missing afterwards. Like Holger_G mentions, the files had not changed at all between the original and upgraded versions of the product. After looking at these files for a while, I discovered that the problematic dll's had different file version information in their fixed headers and variable headers. The fixed header contained a normal period-delimited file version ( The variable header, however, contained a comma-delimited version (6,000,0000,05138).

To me, this suggests that windows installer is using the variable file header for its version comparisons and is thrown off by the commas. Since the files in question come from a third party, I don't have the option of altering their version info. Instead of changing the standard action sequencing (which can have serious consequences), I decided to assign each of the problematic files a companion file. This way windows installer does not use the file's own version info for determining its upgrade behavior, but instead forces the file to follow the behavior of another component (one which upgrades properly).
0 Kudos