3 replies to this topic

[benp44]

Hi all.

I have a really bizarre problem which I am hoping is some sort of 'feature' of windows installer rather than a bug with either windows installer or WISE.

I have moved the call to RemoveExistingProducts in the WISE installer file so that it happens early, i.e. the relevent part of my InstallExecuteSequence table looks like this

InstallValidate 1400
RemoveExistingProducts 1412
InstallInitialize 1425

However, when I compile the MSI and look at it in Orca, the call to RemoveExistingProducts has moved to near the bottom on the sequence!

InstallFinalize 6602
RemoveExistingProducts 6603

The end result is that when I run the MSI to upgrade an older version of the product, it uninstalls the old version (as it should with the early call to RemoveExistingProducts), then installs the new, then uninstalls a load of files again, leaving the new version 'half installed'.

Is this because I have damaged the internal consitency of the MSI or something similar so that the call moves to it's default location? When I run validation on the MSI there are a number of warnings and errors, but none seem particularly related to this.

A solution would be to modify the InstallExecuteSequence table once the MSI has been compiled, but I would rather not have to do this!

Any help would be very welcome to prevent me ripping anymore hair out.

Cheers.

[Zweitze]

This is a bug or feature of Wise, not Windows Installer. Contact the vendor.
To prove that, try changing the value in Orca and save it, then reopen to check whether your value persisted. Note that Orca and Wise use the same functions to compile the MSI.

It's not uncommon that development environments add hidden logic to the install. For instance InstallShield adds quite a few custom actions related to InstallScript. Maybe Wise has a section on 'major upgrade strategies' or something like that?

[benp44]

Thanks for the reply Zweitze.

I have found that if I change the value in ORCA it persists, which in fact is what I am currently having to do to repair the damage (the overnight build programmatically modifies the table).

WISE are notoriously bad a documenting stuff so its been hard work trying to find information. I have logged the bug with WISE so we'll see if they respond.

[Glytzhkof]

Maybe Wise assigns a specific sequence number to the action, and if this number is changed (only slightly), it will leave the action alone and not move it around? Just guessing.