2

When I repair using the msi, a registry entry is properly re-created. When using the exe generated by Burn, the entry is not-recreated, unless the exe associated with the reg entry also requires compare.

I wonder if, when burn invokes msi, if it is overriding the default /fm behavior of msiexec. That switch means "repair all required computer-specific registry entries "

Is there any way I can confirm, deny, or modify that behavior?

Elroy Flynn
  • 3,032
  • 1
  • 24
  • 33

1 Answers1

2

When planning a "Repair" operation in Burn the REINSTALLMODE is "cmuse". For a "Modify" operation the REINSTALLMODE is "cmuso". So "m" is present in both cases.

The Burn log file should say, "Planning action: Action" and that will tell you which it is doing. If you are executing a Repair operation and there is not newer version of the executable on the machine than what your MSI expects, Burn's REINSTALLMODE should work. If you are doing a "Repair", look in the generated MSI log file for the same Burn execution and see what the Component states are for the Components that are not repaired. That should help you track back to see why the Component was not fixed.

From the provided log file:

Command Line: ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 REINSTALLMODE=cmuse
REBOOT=ReallySuppress IGNOREDEPENDENCIES=ALL CURRENTDIRECTORY=C:\temp
CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1

The lack of REINSTALL=ALL shows that EnableFeatureSelection='yes'. Either remove that attribute (or change it to the default 'no') or your BA needs to handle the OnPlanMsiFeature() callback

Rob Mensching
  • 33,834
  • 5
  • 90
  • 130
  • I'm a novice, forgive my ignorance, but.. The word "planning" does not appear in the verbose log. Here are a couple of snippets that might provide useful: MSI (s) (30:70) [22:08:41:379]: ******* RunEngine: ******* Product: {redacted}\Package Cache\{6E84685B-8BBE-485B-8079-CFA1499A954A}v112.100.5415\DataService.generic.x86.msi ******* Action: ******* CommandLine: ********** Command Line: ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 REINSTALLMODE=cmuse REBOOT=ReallySuppress IGNOREDEPENDENCIES=ALL CURRENTDIRECTORY=C:\temp CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1 – Elroy Flynn Mar 14 '13 at 02:14
  • That's the MSI log file. The "planning" step will be in the Bundle log file. – Rob Mensching Mar 14 '13 at 05:31
  • Also, if that is the verbose log file for the MSI then the REINSTALL=ALL is missing which means that you probably set EnableFeatureSelection='yes' on the MsiPackage. A the documentation mentions, "managing feature selection requires special care". If you're not carefully managing feature states, that would explain the problem you are seeing as well. – Rob Mensching Mar 14 '13 at 05:33
  • I'm told that we need EnableFeatureSelection=yes, but I guess we'll have to look more carefully at the implications. – Elroy Flynn Mar 14 '13 at 15:51
  • I'm told that we need EnableFeatureSelection=yes, but I guess we'll have to look more carefully at the implications. here are some bits from the burn log. Plan 2 packages, action: Repair ... Plan 1 msi features for package: x86 Planned feature: Complete, state: Local, default requested: Unknown, ba requested: Unknown, execute action: None, rollback action: None Setting string variable 'WixBundleLog_x86' to value ... Planned package: x86, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register – Elroy Flynn Mar 14 '13 at 15:58
  • Yep, your BootstrapperApplication (BA) is not managing the feature selection the repair for all features is being turned off. If you remove the EnableFeatureSelection='yes' then I expect you'll see things starting to work. Alternatively, your BA will need to handle the OnPlanMsiFeature() callback. – Rob Mensching Mar 14 '13 at 16:28