CODEWITHSUNDEEP
wixwindows-installerbootstrapperburnrepair
Dillon Forzese
Dillon Forzese

Reputation: 23

WiX repair from managed bootstrapper fails to fix some corrupted DLLs

I have a WiX Managed Bootstrapper Application that installs some MSIs. I also have a series of tests that exercise the various functions of the installer. The problem I'm having is with the repair test. The test purposely corrupts all the DLLs we install then calls the EXE installer with "/repair /passive" flags. Once completed around 80% of the DLLs are repaired but the remaining ones are untouched and therefore still corrupted after the repair.

If I manually run msiexec on an individual MSI with the command line args "/fa" which instructs the MSI to forcibly replace all the files it installed, it fixes 100% of the DLLs.

My question is how can I force the MBA to instruct each MSI to repair in this way? I've tried setting the REINSTALLMODE property to 'amus' on the individual MSIs in their .wxs files but the MBA overwrites them at run time as is evident in the log via this line:

PROPERTY CHANGE: Modifying REINSTALLMODE property. Its current value is 'amus'. Its new value: 'cmuse'.

I've also tried to set the properties in the MBA to pass through to each MSI but it doesn't appear to pass them and instead uses it's default values.

I see many similar questions here but none actually address this specific issue. Any help would be greatly appreciated. Rob save me!

Upvotes: 2

Views: 1009

Answers (1)

Brian Sutherland
Brian Sutherland

Reputation: 4798

Here's your problem right here:

[12:25:25:874]: File: C:****\estimator.dll; Won't Overwrite;    Won't patch;    Existing file is unversioned but modified

The installer doesn't want to overwrite a file that has changed since it was installed if it cannot verify the version or language (and maybe some other properties?). Without these properties, it decides to look at the modified date. If it is newer than when it was first installed then it won't touch it assuming instead that something changed for a reason and reverting it will cause something to fail. (You can read more here)

One thing you can do in this case is use a Companion File

Set this attribute to make this file a companion child of another file. The installation state of a companion file depends not on its own file versioning information, but on the versioning of its companion parent. A file that is the key path for its component can not be a companion file (that means this attribute cannot be set if KeyPath="yes" for this file). The Version attribute cannot be set along with this attribute since companion files are not installed based on their own version.

Basically you will set the logic for installing/uninstalling this component to be the same as the "FileID" of another component in the install. In the estimator.dll component, in the File tag, remove KeyPath="yes" and instead replace that with CompanionFile="<NameOfAnotherFileID>".

The issue with this approach is that you may have a corrupted DLL but the companionFile it was linked to was fine so it is not reinstalled.

If this is a dll you do own, I would highly suggest versioning the file! Give it any version you want and this issue should go away.

Another thing you can try, although I don't know how it works really, is giving the file a DefaultVersion

This is the default version of this file. The linker will replace this value from the value in the file if the suppress files option is not used.

This would be the quickest solution to verify. Just build a new installer with DefaultVersion="1.0" in the estimator.dll's <File> and see if it gets replaced. I think this will have the installer think the file is versioned 1.0 but the installed file is not versioned so it will replace it (see here)

Upvotes: 1

Related Questions