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...
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>
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With