Wix Bootstrapper manifest or elevated custom action

5
votes

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.

1
wixcustom-actionbootstrapper
When I was needed to run bootstrapper elevated, I just rebuilt it from source with several manifest files changed. For Wix 3.10 building this way requires VS 2015 with Windows XP support for C++ enabled. I can describe this way if you REALLY need to follow it. – Anton Sutarmin
What I maybe forgot to mention is that we are already building our own UI using Microsoft.Tools.WindowsInstallerXml.Bootstrapper:BootstrapperApplication; I'm not sure if this makes any difference to this topic. Can this custom bootstrapper build be made a normal project that is part of the solution or is it rather a full custom Wix build that is being created using your approach? – Danielku15
it makes no difference. After rebuilding you will have to replace original burn.exe in folder with wix binaries and after it all bootstapper applications built with this binaries will ask for credentials on start. – Anton Sutarmin
Sounds like quite an extreme solution to me to fully recompile Wix and use custom binaries. I saw on the Wix repository that they have a 2 years old issue regarding this topic without any progress. – Danielku15
That's why in first comment I said that I can help if my solution will be appropriate for you :) And even though you'll recompile WIX, you get from it just one burn.exe with only manifest changed. – Anton Sutarmin

1 Answers

2
votes

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.