1

Working with Wix in Visual Studio. I have a public property defined in Product node of wxs file.

<Property Id="MYPROP" Value="123456789"/>

The property value is passed as commandline argument to a deferred custom action executable. I'm able to receive it in the exe as well. The problem is even if I update the Property using vbs (verified through vbs select as well), when I launch the msi, it still passes the default/original value (123456789) to the custom action executable.

Also tried msiexec.exe /i myinstaller.msi MYPROP=SomeOtherValue

I'm still seeing the original value. What's wrong?

tunafish24
  • 2,288
  • 6
  • 28
  • 47

2 Answers2

1

Maybe try this simple thing first:

<Property Id="MYPROP" Secure="yes" Value="123456789"/>

Essentially you need to add a property to the SecureCustomProperties list to have them pass properly to deferred mode in secure desktop environments.

See more information on SecureCustomProperties here. The technical details here are a little bit in flux because of Windows changes, so please just try this first - there could be several other reasons.

How do you use this property? What does it do?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
0

When an msi is run, windows caches the msi file in %windows%\Installer folder. When that msi is run again, windows checks if an msi with identical PackageCode exists in the cache, if so then it uses the cached msi file instead.

PackageCode: identifies each unqiue msi installer package - even if it only has different properties.

In short, when a property is updated using a vbscript etc, then the PackageCode has to be updated as well. This will ensure that after updating msi, the same msi can be used on the same system and windows will not use the cached msi.

tunafish24
  • 2,288
  • 6
  • 28
  • 47
  • So the problem was that you used the same package code hard coded into every package? [This is one "gotcha" of MSI](https://stackoverflow.com/a/38361753/129130). Never hard code package codes - set it to auto-generate (since it is just supposed to be unique). The fact that WiX allows hard coding must be for testing purposes? [I have written about this before](https://stackoverflow.com/a/29872236/129130). Treating something as "identical by definition" is out there for sure... But technology has its quirks. It is basically enforced to force-run from the cached database as you state. – Stein Åsmul Jun 13 '20 at 12:09
  • The package code wasn't hardcoded, however, I was trying to use the same msi file by updating properties through a vbscript. it would work the first time but subsequently use the old values, that was throwing me off. It eventually turned out to be msi caching, now I update package code each time I update a property. Part of the problem is msi is a whole world in itself, so for newbie like me lots of gotchas to run into – tunafish24 Jun 13 '20 at 12:18
  • Is there a way to stop windows from using cached msi and/or not caching msi at all? I've noticed each time I change a property and run msi, windows copies the msi file to %windows%\Installer folder - resulting in many copies of the msi – tunafish24 Jun 13 '20 at 12:23
  • No, it is a core part of the technology. What are you testing? Just change the MSI, uninstall the existing installation and then re-install. You can prevent the MSI from successfully running from the cache when you launch your modified copy by changing the product code in the MSI. Then MSI will **not** treat your MSI as identical to the one installed and it will say "a different version of this product is installed". Uninstall installed version and run the MSI with the changed product code again - it will now install with your changes. – Stein Åsmul Jun 13 '20 at 12:27
  • Note that the system might be in a dirty state after many failed tests. If that is the case, try on a virtual? Or another box? Overall: avoid post-processing your MSI. Change things in the source and re-compile. What changes are you making to the MSI post-build? – Stein Åsmul Jun 13 '20 at 12:30