Odd Bootstrapper Behavior

Mar 15, 2016 at 1:09 PM
In our silent bootstrapper, we noticed that on some machines the build generates a working setup, but that on some machines it does not. After searching through logs, the difference was found to be that on working machines the installer output logs had our msi as default requested: Present, while the build logs from the installers that failed had default requested: Absent. What would be causing this issue given that we are using source control to ensure that all machines have the same Wix and Wix# setups?

Thank you.
Mar 16, 2016 at 6:41 AM
As far as I understood your report the identical WiX source is generated in both cases and "output logs had our msi as default requested: Present" is a fragment from the MSI runtime log. Is this correct?
Mar 16, 2016 at 7:37 PM
I believe that the same WiX source is generated (I didn't find any obvious difference by visual inspection), and the differing default requested settings did come from the MSI runtime log.
Mar 17, 2016 at 1:09 AM
OK. Then I assume what you have in the log a section similar to this (from Wix# samples):
Detected package: NetFx40Web, state: Present, cached: Complete
Detected package: CRT.msi, state: Absent, cached: None
Detected package: My_Product.msi, state: Absent, cached: None
And state Present vs Absent is not evaluated correctly in your case.

If this is the case then you have full control over the package presence evaluation.

Any BA implements a routine responsible for detecting at startup the state of the individual packages and placing the bootstrapper in Install or Uninstall mode. The following is the typical custom implementation of this routine from the WixBootstrapper_NoUI sample:
DetectPackageComplete += (s, e) =>
    //Presence or absence of MyProductPackageId product will be a deciding factor 
    //for initializing BA for Install or Uninstall.
    if (e.PackageId == "MyProductPackageId")
        if (e.State == PackageState.Absent)
        else if (e.State == PackageState.Present)
If you are using the Wix# pre-built SilentBA then you need to let it know what package Id to use as a default/primary one. You can do it by passing it to the BA constructor:
var bootstrapper =
        new Bundle("My Product Suite",
            new PackageGroupRef("NetFx40Web"),
            new MsiPackage(productMsi)
                Id = "MyProductPackageId",
                DisplayInternalUI = true
//if primary package Id is not defined then the last package will be treated as the primary one
bootstrapper.Application = new SilentBootstrapperApplication("MyProductPackageId"); 
Thus if you don't specify the primary package ID and it happens to be not the last one in the chain then you can expect lot's of runtime ambiguity. I hope this helps.
Mar 17, 2016 at 3:32 PM
I made the change you suggested, but the output from the log simply changed to
Planned package: *********, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None,
where the package name was the msi package that we wanted installed before (no effective change, all that changed was the file identifier). I confirmed from other parts of the log that ********** was the primary package id for our silent bootstrapper, that our condition for installation evaluated to true, and the msi built as part of the process that generated the bootstrapper on the machine giving us trouble worked correctly, so I remain unclear on what the issue here could be. Any advice or insight would be greatly appreciated
Mar 17, 2016 at 11:40 PM
I think the only sensible thing to do now is to debug your DetectPackageComplete handler.

Just use the BA app from WixBootstrapper_NoUI sample but with your MSIs and after you enter the routine with the debugger you will be able to see exactly what package is causing invalid Install/Uninstall evaluation.