Wix Bootstrapper manifest or elevated custom action

Question

I know that this is a topic that has been discussed many times and people always claim: Wix bootstrappers should not require to be run elevated. Let me explain our requirement and hopefully anybody can suggest a solution that will work on all systems.

Our installed software is a Windows Service which runs elevated. The service has various settings which are stored in a database that can only be accessed by administrators. The installer also allows the configuration of those settings which is done as part of the elevated phase of the installer. And here is the problem: We cannot load the current settings from the database within the unelevated phase of the bootstrapper.

The easiest solution would be to run the whole boostrapper elevated but it seems that Wix intensively tries to prevent elevated bootstrappers by design. All discussions in this area result in wierd solutions where external tools are used afterwards to embed an application manifest after the Wix compilation.

Yes in theory we could rework the whole database credentials in order to allow the installer read access but I would like to prevent this due to security reasons. We could also keep a copy of the settings for the installer on a readable location (e.g. registry) but this is also not nice to maintain.

Is there some clean Wix-built-in mechanism to load those settings or elevate the bootstrapper from the beginning using an application manifest? We are aware that elevated bootstrappers are "not nice" to the user but our software addresses service operators that anyhow must have administrator privileges in order to operate our software.

Update #1: We already have a custom WPF-GUI as bootstrapper application utilizing the Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplication class provided by Wix.

Answer 1

If it's not necessary for the UI itself to be elevated you can force the install engine to elevate so all the bootstrapper packages will be installed\executed in an elevated mode.

To elevate the engine use the Elevate method of the Engine (the Elevate gets a 'IntPtr hwndParent' parameter - I've used the IntPtr of the window and it worked great).

(Calling the Elevate method will show\pop the UAC elevation screen)

Just keep in mind that the Elevate method is not a blocking operation and from I remember it always returns true. The only way (that I've found) to determine if the elevation actually succeeded is to register to the bootstrapper's Error event and check if the error type is ErrorType.Elevate.

Keep in mind that in this solution the UI itself will remain un-elevated.