custom bootstrapper modification with the same feature selection doesn't rerun MSI package

[demidov250471]

Thank you, Rob, for your reply, but you've closed the issue prematurely.
I've tried "Repair" action long before posting the issue, both, planning it and/or selecting it in "PlanPackageBegin" event.
"Repair" mode ignores cmd properties, apparently, including Burn's as well. So it can't be communicated from the bootstrapper to the package.
On the other hand, repairing is not right, when I only need a "trivial" modification, without optimization. Bare MSI package does that, why doesn't the great bootstrapper? Any modification, whether features have changed or not, should work the same!

[barnson]

WiX doesn't use issues for support. We moved this issue to the experimental GitHub discussions area. You might also consider asking your question on the wix-users mailing list or posting on Stack Overflow.

[barnson]

Burn doesn't run a package unless there's some action for it. As you already use features, set one of those features to be reinstalled and Burn will run it.

[demidov250471]

My MSI doesn't know what repair is, so it can't do something special during repair in particular.
As for repair mode per se, it seems to be Windows Installer limitation. See this thread:
https://www.advancedinstaller.com/forums/viewtopic.php?t=23683.
Actually, "repair" is not "modify", so it makes sense to ignore any intervention into excute sequence.
When I plan repair, all my properties start at their defaults.
On the other hand, repair is not right here, because I do modify the configuration - not via features, but via properties! And any modification should work the same, as it does in bare MSI, when I choose "Change" there and do not modify selection state of any feature - properties still get updated!

[rseanhall]

That link appears to point to an msiexec.exe limitation. Burn calls MsiInstallProduct directly for everything but uninstall (no difference at that level between install, modify, and repair) so properties should work during repair. As Bob said, Burn by design does not run a package unless there's some action for it. Repair is the only way that Burn supports today to force a package to run.

[demidov250471]

Well, they don't. What I do is a standard remeber-me pattern:

This works when I run the MSI package, not the bootstrapper, choose "Change" and modify only the textual field linked to WEBAPIPORT.
In the bootstrapper I have:
... MsiProperty Name="WEBAPIPORT" Value="[WebInterfacePort]" ...
and the corresponding WPF textual field. When bootstrapper is repaired, the property stays the same as it was found in the registry. But when it's modified with some other feature state changed, everything's right.

[rseanhall]

When bootstrapper is repaired, the property stays the same as it was found in the registry.

We would need to see the bootstrapper log and the MSI log from this (in %TEMP%) to see what's wrong.

[demidov250471]

Oh, I'm too lazy for that. Let it be as it is. Besides, I'm strongly against repair for esthetic reasons.
Thank you for your support, though.