WiX MajorUpgrade Schedule="afterInstallExecute" won't overwrite even non-keyPath files

Question

Related to: How to keep a config file when major upgrade in wix v3.8?

Referencing: http://blogs.msdn.com/b/astebner/archive/2008/10/19/9006538.aspx, http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html, http://www.joyofsetup.com/2010/01/16/major-upgrades-now-easier-than-ever/

If I employ <MajorUpgrade DowngradeErrorMessage="A newer version is already installed." Schedule="afterInstallInitialize" /> then the installer works almost as hoped, except that the config file and everything else is removed before the new product files are installed. I totally get that afterInstallInitialize specifies this behavior.

Yet I want to retain the .config file if it has been modified (if the create date and modified date are different) so I set it to keyPath='yes' and attempt to schedule the RemoveExisingProducts to after the reference counts have been incremented with Schedule='afterInstallExecute'.

But when I use afterInstallExecute, it does not behave as I expect during upgrades (works fine as a fresh install). Instead of overwriting the new versions of files that are not marked keyPath='yes' (everything else), all the existing files are left unmodified as their old versions. The installer thinks it was successful anyway.

Each file in my wix has its own component such as:

<Component Id="Host" Guid='*' Win64='yes'>
    <File Source='$(var.root)MyLib.dll' />
</Component>

And:

<Product Id="$(var.productCode)" Language="1033" 
    Version="$(var.version)" UpgradeCode="$(var.upgradeCode)">
    <Package Id="*" InstallerVersion="405" Compressed="yes" Platform="x64"
        InstallPrivileges="elevated" InstallScope="perMachine" />

I'm using WiX 3.8 and the Burn bootstrapper, but if I run the msi without the bootstrapper there's no change. InstallerVersion="405" vs 200 makes no difference.

I don't see any conditions like "skip if already installed" kind of stuff.

What else should I be looking for? Is what I describe the expected behavior?

Thanks!

Note: My Product Version is of the form 0.0.238 and increments with every build. So this should be OK single I'm only using the first three version components.

Here are some highlights from my log file:

• Allowing installation of component: {...} even though a modified unversioned keyfile exists and file versioning rules would disable the component
• ... Won't Overwrite; Won't patch; Existing file is unversioned but modified (for my one .config file. CORRECT!)
• ... Won't Overwrite; Won't patch; Existing file is of an equal version (mostly for DLLs and EXEs)
• ... Won't Overwrite; Won't patch; Existing file is unversioned and unmodified - hash matches source file (mostly for PDBs and XML)

If I specify the -sf linker option, to perhaps force the file version numbers to match the Product's overall version number (as far as Windows Installer is concerned) then the GAC installation fails with "Unknown table 'MsiAssemblyName' in SQL query: SELECT Value FROM MsiAssemblyName". So -sf probably isn't the right trick.

I think I want to avoid updating the .NET assembly version numbers with every build as long as the interfaces don't change and they're just bug fixes. That will make replacement on the installation machine more automatic, right? I'm not even sure if the assembly version change is what's necessary, but I'm fighting it anyway. :-)

Answer 1

I am a bit confused reading this, but provided you have followed the component creation rules you can move RemoveExistingProducts after InstallFinalize. This will remove the old version after installing new files from the new version. This only works properly if the component referencing is correct, but will preserve changed files.

Inserting RemoveExistingProducts early in the InstallExecuteSequence will remove the old version completely, and then reinstall all files - reverting them to default provided they were not set as permanent components in the previous version. I don't think I have ever used the position after InstallExecute - I think you may be mixing up the names.