3 replies to this topic

[vjaksic]

I have a problem creating an msp file, and I am totally desperate. Namely, the patch that I should create should replace two files in the installation folder. However, this does not happen - only one file gets replaced - and the install log mostly ignores the second one. For testing purposes - I created a patch that replaces a dozen files in the installation directory, and they get successfully replaced except this specific one. Also, I have confirmed that the file is not locked by renaming/deleting the file in question. Also, if I manually delete the file from the installation folder, run the patch - the file gets placed on the destination.

 

I have attempted setting the REINSTALLMODE of the updated msi to "a" but to no avail.

 

I am attaching the patch creation log file and the patch installation verbose log file. The file in question is "DflyCredProv64.dll"

 

Any thought on how to bring this problem about?

 

PS since I cannot attach the files in the forum here are gist links:

install verbose log  - https://gist.github....251b0592d036d70

patch creation log -  https://gist.github....cb1aee1e85feb74

Edited by vjaksic, 22 September 2014 - 15:45.

[Glytzhkof]

This is probably a component referencing issue (mismatched component guids for the files between releases) or the file that is not being replaced is not the key path of its component.

 

My advice: abandon the patching approach if you are in a rush and you are not experienced with patching - it really is a headache to get right. Then implement a major upgrade instead. This should be acceptable if your application isn't huge.

 

Some relevant links:

• When should I change or not change my component GUID in WIX?
• WiX patching not updating files correctly
• Patching advice (not great, but might be worth a read)
• Using major upgrades for patches 

Update:

 

...if I manually delete the file from the installation folder, run the patch - the file gets placed on the destination.

 

 

This could indicate that the file is either not versioned, or the version number is the same in the new setup whilst the file itself is binary different. Is this the case? If so you should increment both the file and product versions for the file (recompile) in question and then recreate your patch. If the file is unversioned, you can set a companion file and then recompile the patch. Finally you can try to install the existing patch with REINSTALLMODE = emus and see if this updates the file in question.

Edited by Glytzhkof, 23 September 2014 - 00:00.

[vjaksic]

The file is a key path of the component. The component GUID has not changed. The "emus" mode has not helped. I still have not tried out the companion file because I do not know how to set it up in the tool that I am using (WISE).

[Glytzhkof]

As you will see if you follow the link provided for the companion file concept, you can open and change the compiled MSI directly using Orca or Wise after you compile it with Wise and set the Version field equal to the file identifier you want to "version follow". As far as I recall it is also possible to set the companion file from within the Wise wizard views.

 

Here is the screen shot of how the finished MSI should look like with the companion file version setting shown in yellow. As you see it is very simple, the version field specifies what file you rely on for versioning (capitalization might matter, I can't recall) - never mind the irony that this particular EXE file appears to not have a proper version field - the overall concept should be clear however, you add the file to rely on for versioning to the Version field of the file that is to be version controlled:

 

 

The proper Main.exe content in the File table should be:

• Main.exe - Mainexe - Main.exe - 2117632 - 1.0.0

 

It is odd that the emus setting doesn't work - this must mean the file is unversioned? If this is the case you should definitely use a companion file due to the rather odd Windows Installer File Versioning Rules. Essentially non-versioned files won't be replaced if the create and modify dates are different (which means they have been changed since they were installed). The companion file overrules this non-versioned logic.

Edited by Glytzhkof, 03 February 2015 - 10:52.