Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How do I install with elevated permissions using a WiX installer?

Tags:

wix

We currently have an MSI that is created with WiX 3.5. The application is in .NET 3.5. We generate a bootstrapper using the boostrapper task in an MSBuild file. It's pointing at the 6.0a SDK files.

When users have UAC on and they install, they have to right-click the setup.exe and select run-as administrator.

What I would really like is to have the setup.exe automatically prompt to elevate (using that yellow dialog I see in other installs).

Better yet, I'd like the MSI to do this and do away with the setup.exe completely, but I think that is what WiX 3.6 is about, right?

If I create the boostrapper using ApplicationRequiresElevation="true" this requries the 7.0a SDK, correct? Will the bootstrapper then prompt to elevate automatically? Does this mean the application has to be a .NET 4 application? I wouldn't think so...

like image 851
Jonesie Avatar asked Jan 04 '12 02:01

Jonesie


2 Answers

We've used WiX 3.0 and were able to elevate privileges. However, we didn't elevate our bootstrapper. We elevated the MSI file itself, through the Package property:

<Package Id="$(var.PackageCode)"
         Description="$(var.ProductName) $(var.Version)"
         InstallerVersion="301"
         Compressed="yes"
         InstallPrivileges="elevated"  <!-- Elevated right here -->
         InstallScope="perMachine"
         Platform="x86"/>

As a side note, our bootstrapper is signed (using signtool.exe from the v6.0A SDK) with our official certificate. I'm not sure if this causes the bootstrapper to also require elevated privileges.

UPDATE:

We've got an app.manifest file on our setup.exe bootstrapper project that requires the executable to be run at the administrator level. See the sample below:

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"
                xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
                xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <!-- UAC Manifest Options
            If you want to change the Windows User Account Control level replace
            the requestedExecutionLevel node with one of the following.

        <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
        <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
        <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

            If you want to utilize File and Registry Virtualization for backward
            compatibility then delete the requestedExecutionLevel node.
        -->
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>
</asmv1:assembly>
like image 195
Jason Down Avatar answered Oct 20 '22 12:10

Jason Down


I know this is a old topic, but may it save some time to next one.
I had to read all comment, especially custom action had Impersonate=yes...

On the other hand Custom Actions have Execute attribute related to privileges:

<CustomAction Id = "CA.First"  Execute ="immediate" ... />
<CustomAction Id = "CA.Second" Execute ="deferred"  ... />

CA.First will be always executed in user mode, but CA.Second can have elevated privileges.

May be here are other tricks related to privileges,
main point here - WiX allow control privileges on CustomAction level so make sure you set it right.

CustomAction Element

like image 33
Igor O Avatar answered Oct 20 '22 12:10

Igor O