[wix-users] Elevated CA before GUI?

[Rob Mensching]

1. Restart manager is about preventing restarts: http://robmensching.com/blog/posts/2005/12/10/in-defense-of-windows-vistas-restart-manager/

2. The MsiPackage/@DisplayInternalUI feature is buggy. It will not be removed in v3 (no breaking changes) but could be deprecated and removed in v4. The Windows Installer interaction is fundamentally flawed and we didn't realize it when we introduced the feature.

3. There are all kinds of very good reasons to use Burn but (as should be abundantly clear from this thread now) using Burn to try to subvert the Windows Installer's design that UI runs unelevated is not one of them.

4. Nobody has explained why they must elevate their setup UI, just that they want to. The focus should be on addressing that perceived design requirement and trying to adapt it to reality.

_____________________________________________________________
 Short replies here. Complete answers over there: http://www.firegiant.com/


-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Robert Goodridge
Sent: Thursday, August 18, 2016 10:46 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Elevated CA before GUI?

Yes there are issues running the whole msi elevated. The problem we are trying to solve is needing access to resources that require admin rights during the UI phase. As Rob says, that means you need to run the whole MSI elevated. For our purposes, not having access to mapped drives does not matter. If it did we would already have a problem with the bare MSI. Running our MSI in an elevated command prompt works. Its just messy. You can't click on the msi and run it from explorer. 

Thanks Rob for making me think about why the Uninstall needed to be elevated. It was not about the UI. There were other resources that required elevation that were running after the Server process. They've been fixed now - by running them deferred. So that constraint has been lifted.

Restart Manager seems to be about re-booting the machine. I can't see how that helps the UI.

If CloseApplications is a deferred Custom Action, that cannot help either.

So even though Burn is documented to run the MSI's UI, that may be removed in the future? Really?

So there are no provided solutions to run the UI elevated.

If that had been documented I would have not started using Burn in the first place, and gone with my initial thought which seemed like it would take longer. Bundle the MSI in my own exe.

Warm regards

Rob Goodridge | CloudArchitect | LANSA Product Centre

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Magi, Sampattakumar S
Sent: Friday, 19 August 2016 3:18 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Elevated CA before GUI?

One problem I faced when I ran UI elevated (either elevated cmd or making setup.exe runas Admin).

We can't see a network mapped drive if we want it to make use of it using BrowseDlg and even if u give path manually it throws an error.

Regards
Sampat



-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Rob Mensching
Sent: Friday, August 19, 2016 10:20 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Elevated CA before GUI?

If the requirement is to "Run the UI elevated" then by definition the only way to address the problem is to run the UI elevated.

Using Burn isn't the really the correct solution because Burn is designed to show UI and suppress the MSI UI sequence. If you must elevate the UI then it'd make more sense to have an executable that shows no UI that starts the MSI elevated.
 
The fundamental problem is that launching the UI elevated is the wrong problem to solve.

Phil recommended Restart Manager, a great solution (Vista+).  CloseApplications was also mentioned, which is a deferred custom action.

Those are the provided solutions to run code elevated.

So, what you've seen is people here trying to challenge the problem definition before resorting to hacking around the systems' designs.



PS: Uninstall doesn't run the MSI UI sequence so elevated UI isn't even a thing there.

PPS: Future releases of Burn may not support "DisplayInternalUI". There are currently unsolvable problems with "DisplayInternalUI".

_____________________________________________________________
 Complete answers over there: http://www.firegiant.com/


-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Robert Goodridge
Sent: Thursday, August 18, 2016 6:38 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Elevated CA before GUI?

So I gather from the no response that there isn't actually a solution apart from mine?

Bob raised these issues:
* It relies on an undocumented implementation detail.
I suspect that it will never change. To elevate the msi, Burn probably runs the whole process elevated. How else would it be done?

* It breaks the ability to use the .msi normally outside the bundle.
Not quite correct. 
Bundling is not breaking the MSI. The MSI is already 'broken'.
You may run the msi inside an elevated command prompt and that will run the whole install elevated.
And then the Uninstall is messy. You have to run the uninstall from inside an elevated command prompt. Running it from Programs and Features gets errors.
We've lived with all that because we have to, as far as we know. ...until bundling

* There's existing built-in and standard functionality that solves the problem.
That seems to be deferred custom actions and they don't run in the UI part of the install. So that's not a solution.

Warm regards

Rob Goodridge | CloudArchitect | LANSA Product Centre