Using Enhanced UI/bootstrapper breaks a lot of standard MSI behavior

[sbaird]

I've made a couple other posts lately as I discover these issues, but more keep popping up, and I'm quickly losing confidence in AI's implementation of the Enhanced UI functionality. We chose AI in large part because of its UI editing/theming capabilities, which of course requires an Enhanced UI/bootstrapper-based setup, but we also need standard MSI functionality to be in place and working.

[*]We write the UILevel property to the registry for bookkeeping purposes. This works as expected except when running with reduced UI (/qr switch). In this case, the UILevel is correctly set to 4 during the UI sequence, but during the execute sequence (when the registry value is written) it is set to 5 (full UI). I'm inferring that the bootstrapper is calling msiexec twice (once for each sequence) as part of the Enhanced UI implementation, and it is not retaining command line parameters and certain property values from the first execution.

[*]msiexec switches specified after a property on the command line are lost during the execute sequence. For example, with the following command line:
Setup.exe /qr PROPERTY=value /l*v log.txt, the /l*v log.txt is not passed to msiexec for the execute sequence and logging only occurs during the UI sequence. If the switch is placed before PROPERTY=value, logging works correctly during both. Windows Installer does not mandate that command line switches must precede all properties on the command line, and if AI imposes such a restriction, it seems to me it should at least be an error condition if not met. Diagnosing these non-standard behaviors is time consuming for our team.

[*]The log file flow seems to be non-standard. I do not see the normal client-side properties dump at the end of the log nor the standard: "Product: [Product] -- Installation completed successfully." message and similar messages when running a bootstrapper-based package.

[Daniel]

Hello,

Please check my replies below.

[*]We write the UILevel property to the registry for bookkeeping purposes. This works as expected except when running with reduced UI (/qr switch). In this case, the UILevel is correctly set to 4 during the UI sequence, but during the execute sequence (when the registry value is written) it is set to 5 (full UI). I'm inferring that the bootstrapper is calling msiexec twice (once for each sequence) as part of the Enhanced UI implementation, and it is not retaining command line parameters and certain property values from the first execution.

Indeed, this seems to be an Enhanced User Interface limitation. We will investigate this issue and will try to add an improvement in a future version of Advanced Installer. We'll update this thread when a fix will be out. Until then, as a workaround, you can use your own custom action (scheduled during Wizard Dialogs Stage) to write the "UILevel" property in the registry.

[*]msiexec switches specified after a property on the command line are lost during the execute sequence. For example, with the following command line:
Setup.exe /qr PROPERTY=value /l*v log.txt, the /l*v log.txt is not passed to msiexec for the execute sequence and logging only occurs during the UI sequence. If the switch is placed before PROPERTY=value, logging works correctly during both. Windows Installer does not mandate that command line switches must precede all properties on the command line, and if AI imposes such a restriction, it seems to me it should at least be an error condition if not met. Diagnosing these non-standard behaviors is time consuming for our team.

I've tested the scenario and replicated the behavior. This seems to be another EUI limitation. We'll consider a fix for this in a future version of AI, thank you for bringing it to our attention. We'll notify you when a fix will be out.

[*]The log file flow seems to be non-standard. I do not see the normal client-side properties dump at the end of the log nor the standard: "Product: [Product] -- Installation completed successfully." message and similar messages when running a bootstrapper-based package.

Please note this is our default way of logging when using the EUI feature. This is because our EUI feature substitutes the standard msiexec client process and when logging it doesn't add in the log the related properties and standard "Installation completed successfully" message.

All the best,
Daniel

[sbaird]

Thanks so much for your quick responses.

Indeed, this seems to be an Enhanced User Interface limitation. We will investigate this issue and will try to add an improvement in a future version of Advanced Installer. We'll update this thread when a fix will be out. Until then, as a workaround, you can use your own custom action (scheduled during Wizard Dialogs Stage) to write the "UILevel" property in the registry.

Thanks for the suggestion. I decided to use a different workaround which I find to be more flexible -- I'll describe it here in case anyone else can make use of it:
I create another public property and associate it with a hidden edit box on the UI, then set this property from the value of UILevel in the UI sequence. I then set the UILevel back from the value of this property at the start of the execute sequence. This "trick" will work for any public property which otherwise wouldn't get passed to the execute sequence because of the Enhanced UI implementation issue. I find this cleaner because I don't have to worry about an uninstall custom action to remove the registry value, and I also don't have to worry about whether the UI sequence runs or not.

I look forward to the aforementioned fixes.

[Daniel]

Hello,

[*]We write the UILevel property to the registry for bookkeeping purposes. This works as expected except when running with reduced UI (/qr switch). In this case, the UILevel is correctly set to 4 during the UI sequence, but during the execute sequence (when the registry value is written) it is set to 5 (full UI). I'm inferring that the bootstrapper is calling msiexec twice (once for each sequence) as part of the Enhanced UI implementation, and it is not retaining command line parameters and certain property values from the first execution.

Indeed, this seems to be an Enhanced User Interface limitation. We will investigate this issue and will try to add an improvement in a future version of Advanced Installer. We'll update this thread when a fix will be out. Until then, as a workaround, you can use your own custom action (scheduled during Wizard Dialogs Stage) to write the "UILevel" property in the registry.

Our development team has further investigated this and it seems this is a limitation of our EXE bootstrapper implementation which is quite difficult to be fixed. This is why we cannot offer any ETA for such a fix and instead we strongly advise to workaround against this issue by simply using an additional property which will store the value of "UILevel" property during UI Stage and restore its value on Install Execution Stage.

For instance you can implement the following approach:

1. go to "Custom Actions" page and add a "Set installer Property" custom action with sequence scheduled after "Wizard Dialogs Stage -> Paths Resolution" action group like this:

• Property: UI_LEVEL
  Value: [UILevel]
  Condition:

2. add another "Set installer Property" custom action with sequence scheduled before "Install Execution Stage -> Searches" action group like this:

• Property: UILevel
  Value: [UI_LEVEL]
  Condition: UI_LEVEL

Hope this helped.

All the best,
Daniel

[Catalin]

Hello,

This was fixed in version 15.7 of Advanced Installer released on February 13th, 2019.

All the best,
Catalin

[sasha]

Resurrecting a really old thread. It appears the UILevel value is still set to 5 when using the /qr parameter with the .exe installer.
Here is some logging from the log file:

MSI (c) (50:C0) [11:58:01:327]: PROPERTY CHANGE: Adding EXE_CMD_LINE property. Its value is '/exenoupdates /forcecleanup /wintime 1735336196 /qr /l*v! "C:\Users\sasha\AppData\Local\Temp\log8769.log" AI_DEBUGLOG=1 '.

Line 91: MSI (c) (50:C0) [11:58:01:187]: PROPERTY CHANGE: Adding UILevel property. Its value is '4'.
Line 532: MSI (c) (D8:6C) [11:58:04:765]: PROPERTY CHANGE: Adding UILevel property. Its value is '4'.
Line 804: MSI (s) (64:4C) [11:58:05:593]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'.
Line 2639: Property(S): UILevel = 5

Using the AI v21.7.1

[sasha]

I worked around this issue by using the `AIEXTERNALUI` property instead of UILevel. It is correctly set to the value `4` when the /qr is used.

[Liviu]

Hello,

Thank you for your followup on this.

I'm glad to hear that it's working now.

Best regards,
Liviu

[sasha]

Well, as far as the `UILevel` is concerned, it doesn't work. A workaround (luckily there is an AI-specific property!) works, which is a bit different

[Catalin]

Hello Sasha,

Indeed, the External UI changes some things, especially when it comes to UI and some other controls.

In your case, I'm not sure whether it is a workaround or the actual valid solution.

I will discuss this with the dev team and will followup here once I'll have more information.

Best regards,
Catalin

[sasha]

Fantastic, thanks!
A great solution could be just a matter of documenting what should be used where.

I find it surprising that the `\qb` works with the `UILevel` and `\qr` doesn't. Of course, I have no idea what's happening under the hood.

[Catalin]

You are always welcome!

I have created a ticket now as this can not be the normal behavior of this, especially considering it works with the /qb parameter.

Once I'll have more information, I'll update this thread.

Thank you for bringing this to our attention!

Best regards,
Catalin

[Catalin]

Hello Sasha,

This has been fixed in version 23.4 of Advanced Installer.

Best regards,
Catalin