Downgrading a DLL during an upgrade

[coderafk]

Hello Oleg,

what are the options for downgrading a DLL during an upgrade?

We have noticed that a newer version of a DLL is causing problems, and we need to replace it with an older version during an upgrade.

Unfortunately, the overwrite property of File does not work, as it is already determined during CostInitialize that this file cannot be installed.

MSI (s) (7C:78) [07:34:42:411]: Disallowing installation of component: {E83F48D2-FE7A-4D41-A891-554C88662C30} since the same component with higher versioned keyfile exists

At the moment we solve the problem by testing whether this DLL exists in a separate CustomAction before CostInitialize and then deleting it. This works, but I don't find this workaround very elegant. (Later I will probably move this functionality to WixSharp_Load_Action).

Do you know a better way?

Best Frank

[oleg-shilo]

Hi Frank,

We have noticed that a newer version of a DLL is causing problems, and we need to replace it with an older version during an upgrade.

I am puzzled about that. With MSI MajorUpgrade works by auto-uninstalling the old version of the product and replacing it with a new one. Thus I expect the faulty dll to be removed on the target system after auto-uninstall. MajorUpgrade should be the straight forward solution for you.

I am not sure why it is not happening in your case.

[coderafk]

Hello Oleg,

we currently use the MajorUpgrade element as follows:

project.MajorUpgrade = new MajorUpgrade
{
    Schedule = UpgradeSchedule.afterInstallValidate,
    AllowDowngrades = true
};

However, the problem is that the files are already marked during CostInitialize that they should not be replaced because a higher version of these files is already installed.

MSI (s) (7C:78) [07:34:42:411]: Disallowing installation of component: {E83F48D2-FE7A-4D41-A891-554C88662C30} since the same component with higher versioned keyfile exists

During an update, all files of the old version are first uninstalled and then the new files are installed, but unfortunately without these marked DLLs.

Have I missed something?

Best Frank

[Torchok19081986]

Hallo, very intresting post. Accoding to Stackoverflow

Here’s a breakdown of what might be happening:

Component Version Conflict: The MSI installer is detecting that a component with the same identifier ({E83F48D2-FE7A-4D41-A891-554C88662C30}) but with a higher version already exists. MSI handles components by their GUIDs, and if it finds a component with the same GUID but a higher version, it might block the installation of the lower version to avoid conflicts.

Component Keyfile: The keyfile mentioned in the error log is used by MSI to check for version conflicts. The component’s keyfile helps MSI to determine if the same component exists with a different version.

Wix Toolset: When using Wix Toolset, ensure that your component versions are properly managed and incremented. Wix Toolset might be checking the version numbers and GUIDs to prevent downgrades or conflicts.

Doesnt File has property to overwrite file on Install ? default is false. What happens if you set this property of Dll to true?

[oleg-shilo]

Hi Frank, Apologies for not responding earlier. @Torchok19081986 suggested a workaround that I would also try to use. WixSharp has very little to offer when it comes to the MSI deployment algorithms, thus I would try to use whatever MSI has as the first line of defence.