3 replies to this topic

[JimboH]

I am working on a new Basic MSI install in IS 2015 Professional, it is a major upgrade of a product that was previously installed with an installscript MSI (that I think was made in 2012).

The version, product, and package code are different and they share an upgrade code.

The old install gave the option to install for all users or just the current user, the new install is currently set to be 'all users' only.

When testing in virtualbox (having installed the old version for 'all users'), the old install uninstalls, and the new version installs successfully, but a broken entry remain in Add/Remove Programs for the old version. A new entry for the new version is of course also present.

The frustrating part is I am sure I had this working at one point (initially I had problems because I had not setup an upgrade path), but I do not know what I might have changed to to cause this error.

Any ideas how I can fix this or where to look next?

[deramor]

I've run into this when performing major upgrades of Installscript MSI -> installscript MSI projects.

 

Try this:

 

Create a Deferred Custom action (Installscript code)

I scheduled mine after WriteRegistryValues with condition: REMOVE="ALL" AND UPGRADEINGPRODUCTCODE

UPGRADEINGPRODUCTCODE is a predefined property that contains the Product Code for the version performing the upgrade.

I use it simply as a flag to tell me that an upgrade it happening.

 

The code should simply be:

 

function RemoveARPEntry_OnMajorUpgrade(hMSI)
begin

    RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE);
    RegDBDeleteKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\InstallShield_"+PRODUCT_GUID);
    
end;

 

Note that this is being executed by the product already installed on the system.  This is why it:

1. Needs to know there is an upgrade happening

2. Only needs to know about its own product code.

 

Good luck.

[JimboH]

Thank you for your response, it helped me find a solution.

I didn't want to add any installScript to the basic MSI project however, as I am hoping we can eventually migrate to WiX (and am assuming I couldn't use it then) also the previous install (the one that was an installScript MSI) has been long deployed.

 

Here is what I ended up doing:

I ended up with 2 CA's one for 32 bit and one for 64 bit.

The 64-bit: "[SystemFolder]cmd.exe" /C "echo y | reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_[ISACTIONPROP1]"

 

As a commit execution CA with execute condition: VersionNT64 AND IS_MAJOR_UPGRADE

 

Where "ISACTIONPROP1" is defined in an upgrade path (as the "Detect Property") to hold the previous product code.

 

The CA's execute in the Install Exec (after "WriteRegistryValues" and Admin Exec sequence (after "ScheduleReboot").

 

The 32-bit CA is almost identical except the condition has "NOT VersionNT64" and the registry path is different (basically w/o the Wow6432 in the path to the key).

[deramor]

It is important to note that this key would show up in the registry not according to the bitness of the OS but rather through a combination of the bitness of the installation and OS.

 

If your installer uses x86 or Intel in the Template Summary setting on the Gerneral Information screen, then you have a native 32-bit installation.

On 64-bit OSs, you would need to remove the installshield guid from the wow node.  This is done through a 64-bit process however.

On 32-bit OSs, you would need to omit the wow node from your path and use a 32-bit process to perform the delete.

 

 

If instead you have x64 in Template summary, your installer is now a native 64-bit process.

It will then only put its old installshield guid in the 64-bit registry so you would not need a wow node path.