¿Cómo instalo con permisos elevados usando un instalador de WiX?

Actualmente tenemos un MSI creado con WiX 3.5. La aplicación está en .NET 3.5. Generamos un bootstrapper usando la tarea boostrapper en un archivo MSBuild. Está apuntando a los archivos 6.0a SDK.¿Cómo instalo con permisos elevados usando un instalador de WiX?

Cuando los usuarios tienen instalado UAC e instalan, tienen que hacer clic con el botón derecho en setup.exe y seleccionar administrador de ejecución.

Lo que realmente me gustaría es que setup.exe solicite automáticamente elevar (usando ese cuadro de diálogo amarillo que veo en otras instalaciones).

Mejor aún, me gustaría que el MSI haga esto y elimine por completo el setup.exe, pero creo que de eso se trata el WiX 3.6, ¿no?

Si creo el boostrapper usando ApplicationRequiresElevation="true" esto requiere el SDK de 7.0a, ¿correcto? ¿El iniciador luego le pedirá que se eleve automáticamente? ¿Esto significa que la aplicación tiene que ser una aplicación .NET 4? No lo creo ...

Fuente

2012-01-04 Jonesie

Hemos utilizado WiX 3.0 y hemos podido elevar los privilegios. Sin embargo, no elevamos nuestro bootstrapper. Elevamos el archivo MSI en sí, a través de la propiedad del paquete:

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

Como nota al margen, se firma nuestro programa previo (utilizando signtool.exe desde el SDK v6.0A) con nuestro certificado oficial. No estoy seguro de si esto hace que el programa de arranque también requiera privilegios elevados.

ACTUALIZACIÓN:

Tenemos un archivo app.manifest en nuestro proyecto de programa previo Setup.exe que requiere el ejecutable que se ejecute en el nivel de administrador. Vea el ejemplo a continuación:

<?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>

Fuente

2012-01-04 02:53:49

Gracias, ya tengo InstallPrivleges establecidos como esto pero, duerma parece hacer nada útil. La ejecución de la MSI directamente no se elevará. Ah, pero acabo de notar que InstallerVersion está configurado en 300. Me pregunto si eso es todo ... – Jonesie

@ Jones: Si no obtienes una buena respuesta antes de mañana, echaré un vistazo más de cerca a nuestras cosas cuando 'Estoy en el trabajo. Es posible que pueda obtener más información. –

¡Salud, amigo! Necesito ejecutar esto a través de nuestro servidor de compilación, que demora una hora, por lo que es bastante lento intentar 1 cosa a la vez :) – Jonesie

Sé que este es un tema antiguo, pero puede ahorrarle tiempo al siguiente.
tuve que leer todos los comentarios, especialmente custom action had Impersonate=yes...

En las otras acciones mano de encargo han Ejecutar atributo relacionado con privilegios:

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

CA.First serán siempre se ejecuta en modo de usuario, pero CA.Second privilegios se han elevado .

Puede encontrar otros trucos relacionados con los privilegios,
punto principal aquí - WiX permite privilegios de control en el nivel de acción personalizada, así que asegúrese de configurarlo correctamente.

CustomAction Element

Fuente

2017-09-21 12:54:32

¿Cómo instalo con permisos elevados usando un instalador de WiX?

Respuesta

Cuestiones relacionadas