Command line arguments swallowed by burn - affecting related bundle detection

[OndrejVrsan]

Bug

• Which version of WiX are you building with?

3.11.0.1701

• Which version of Visual Studio are you building with (if any)?

VS 2017 15.6.6

• Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

0.9.21.62588

• Which version of .NET are you building with?

.NET Framework 4.6

• If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

Windows 10 v1703

• Describe the problem and the steps to reproduce it.

I'm using Managed Bootstrapper Application
The application supports silent installation from command line. It implements argument switches.
However, when passing single argument - one of -?, -h or -help - zero arguments is delivered to Bootstrapper application.
I suspect they are swallowed by burn engine.
Also detection of related bundles is in this case weird. The DetectRelatedBundle event is fired, but its DetectRelatedBundleEventArgs have only Version property populated, other properties have default values.

• Describe the behavior you expected and how it differed from the actual behavior.

When I use e.g. help argument switch (note that there are no dash), the argument is delivered to the app and detection of related bundles works as expected i.e. Operation property is populated with e.g. RelatedOperation.Downgrade (when already installed bundle has higher version) etc.
I expect same behavior with any other arguments, i.e. that -?, -h or -help are delivered to the application and related bundle detection works consistently no matter of arguments passed.

[barnson]

Burn removes the standard command line switches it knows about and sends the remaining arguments to the BA. So -h turns into an action of BOOTSTRAPPER_ACTION_HELP and -q turns into a display of BOOTSTRAPPER_DISPLAY_NONE. BAs can't parse those switches but that shouldn't affect parsing of other switches or arguments. Can you attach bundle logs showing the problem?

[OndrejVrsan]

Well, if removing well-known burn arguments is desired behavior, then it is ok, that running installer with single parameter -h results to zero arguments delivered to BA.

However, there should be no difference running the installer with -h or with no arguments then... The difference actually is in detection of related bundle.

I've attached logs of running same installer executable (while having different build of related bundle already installed on my computer). I've run it once with well-known burn argument, once without arguments.

Log of installer execution > Foo_12.0.exe -h
Foo_12.0_BOOTSTRAPPER_ACTION_HELP.log

Log of installer execution > Foo_12.0.exe
Foo_12.0_NO_PARAMETERS.log

When you compare the logs, you can see a difference
Detected related bundle: (...) operation: None vs.
Detected related bundle: (...) operation: MajorUpgrade
and
Variable: WixBundleAction = 1 vs.
Variable: WixBundleAction = 5

In both cases, BA is running without parameters, because the -h was actually taken by-design by burn (as you wrote above). I expect that there should be no difference in related bundle detection.

As a workaround, I'm detecting related bundle in my BA code using following code, so it works correctly and consistently, no matter arguments passed to BA.

private void DetectedRelatedBundle(object sender, DetectRelatedBundleEventArgs e)
{
    var installerVersion = Engine.VersionVariables["WixBundleVersion"];

    if (e.Version != installerVersion)
    {
        Engine.Log(LogLevel.Verbose, $"Foo of different version ({e.Version}) than this installer ({installerVersion}) is installed on this computer");
        // ...
    }
}

Note that in this code would not be possible to use e.Operation, because it is set to RelatedOperation.None when running installer with well-known burn argument.

[rseanhall]

Unlike Plan, Detect doesn't have a parameter for the intended BOOTSTRAPPER_ACTION so it appears to be using the action specified on the command line which in this case would be BOOTSTRAPPER_ACTION_HELP. Under the HELP action, the operation for that package would be None.

Bundles aren't expected to try to actually do anything with the engine when the HELP action is specified on the command line. I guess we'd have to add the BOOTSTRAPPER_ACTION as a parameter to Detect in order to support what you're trying to do here.

[barnson]

The Help and Layout actions are "special" and designed to skip normal Burn phases like Detect. So a help action is showing the correct operation -- during Help, related bundles won't be acted on so operation: None is correct.

[OndrejVrsan]

But since no arguments are delivered to BA, we have no way how to detect that burn run "special" action, our custom installer GUI starts up and is in invalid state, because Detect phase did not run.
I don't see any messages from burn when running installer from command line with -h. The custom BA just starts up... Or do we have something implemented wrong?

[robmen]

The BOOTSTRAPPER_COMMAND provided to PFN_BOOTSTRAPPER_APPLICATION_CREATE contains the action of type of BOOTSTRAPPER_ACTION. It should be set to BOOTSTRAPPER_ACTION_HELP in this situation. There is lots of useful information in there for a BA.