installer - para - wix editar codigo

¿Cómo ejecutar un script en WiX con una acción personalizada, el ejemplo más simple posible?

Question

Pregunta de Novato WiX: ¿Cómo puedo
1. Copie un script de shell de un solo uso para templar junto con el instalador
p.ej

 <Binary Id=''permissions.cmd'' src=''permissions.cmd''/> 

2. Encuentre y ejecute ese script al final de la instalación.
p.ej

<CustomAction Id=''SetFolderPermissions'' BinaryKey=''permissions.cmd''
ExeCommand=''permissions.cmd'' Return=''ignore''/>
<InstallExecuteSequence>
<Custom Action="SetFolderPermissions" Sequence=''1''/>
</InstallExecuteSequence> 

Creo que tengo al menos tres problemas:

• No puedo encontrar permisos.cmd para ejecutarlo. ¿Necesito [TEMPDIR] permissions.cmd o algo así?
• Mi secuencia llega demasiado pronto, antes de que el programa esté instalado.
• Necesito cmd / c permissions.cmd en algún lugar de aquí, probablemente cerca de ExeCommand ?

En este ejemplo, permissions.cmd usa cacls.exe para agregar al usuario interactivo con permisos de escritura a % ProgramFiles% / Vendor ACL. También podría usar secureObject : esa pregunta es "¿Cómo agrego el usuario interactivo a un directorio en un Windows localizado?"

Answer 1

¿Tienes un ejemplo de cómo se usa esto? Quiero decir, ¿utilizo CreateFolder anidado bajo el directorio cuya ACL quiero cambiar? ¿O utilizo CreateFolder primero, por separado? ¿Es el siguiente incluso cerca?

<Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
<Fragment>
<DirectoryRef Id="TARGETDIR">
<Directory Id=''ProgramFilesFolder'' Name=''PFiles''>
<Directory Id="directory0" Name="MyApp" LongName="My Application">
<Component Id="component0" DiskId="1" Guid="AABBCCDD-EEFF-1122-3344-556677889900">
<CreateFolder>
<Permission User=''INTERACTIVE''
GenericRead=''yes''
GenericWrite=''yes''
GenericExecute=''yes''
Delete=''yes''
DeleteChild=''yes'' />
<Permission User=''Administrators'' GenericAll=''yes'' />
</CreateFolder>
<File Id="file0" Name="myapp.exe" Vital="yes" Source="myapp.exe">
<Shortcut Id="StartMenuIcon" Directory="ProgramMenuFolder" Name="MyApp" LongName="My Application" />
</File>
</Component>
<Directory Id="directory1" Name="SubDir" LongName="Sub Directory 1">
<Component Id="component1" DiskId="1" Guid="A9B4D6FD-B67A-40b1-B518-A39F1D145FF8">
etc...
etc...
etc...
</Component>
</Directory>
</Directory>
</DirectoryRef>
</Fragment>

Answer 2

En lugar de ejecutar una acción personalizada, puede intentar usar el elemento Permiso como elemento secundario del elemento CreateFolder, por ejemplo:

<CreateFolder>
<Permission User=''INTERACTIVE'' GenericRead=''yes'' GenericWrite=''yes''
GenericExecute=''yes'' Delete=''yes'' DeleteChild=''yes'' />
<Permission User=''Administrators'' GenericAll=''yes'' />
</CreateFolder>

¿Esto sobrescribe o simplemente edita la ACL de la carpeta?

Según la documentación de MSDN sobrescribe:

Cada archivo, clave de registro o directorio que figura en la tabla LockPermissions recibe un descriptor de seguridad explícito, ya sea que reemplace o no un objeto existente.

Lo confirmé ejecutando la instalación de prueba en Windows 2000.

Answer 3

Aquí hay un ejemplo de trabajo (para establecer permisos, no para ejecutar un script):

<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder" Name="PFiles">
<Directory Id="BaseDir" Name="MyCo">
<Directory Id="INSTALLDIR" Name="MyApp" LongName="MyProd">
<!-- Create the folder, so that ACLs can be set to NetworkService -->
<Component Id="TheDestFolder" Guid="{333374B0-FFFF-4F9F-8CB1-D9737F658D51}"
DiskId="1" KeyPath="yes">
<CreateFolder Directory="INSTALLDIR">
<Permission User="NetworkService"
Extended="yes"
Delete="yes"
GenericAll="yes">
</Permission>
</CreateFolder>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>

Tenga en cuenta que esto está usando ''Extended ='' Yes ​​'''' en la etiqueta Permiso, por lo que está utilizando la tabla SecureObjects y la acción personalizada, no la tabla LockPermissions (consulte Documentos de WiX para Elemento de permiso ). En este ejemplo, los permisos aplicados al directorio MyProd por SecureObjects son heredados por los subdirectorios, que no es el caso cuando se utiliza LockPermissions.

Answer 4

Encontré la publicación del blog De MSI a WiX, Parte 5 - Acciones personalizadas: Introducción útil cuando quería entender CustomActions en WiX.

También puede encontrar la definición de CustomAction y sus atributos en CustomAction Element .

Tienes que hacer algo como esto

<CustomAction Id="CallCmd" Value="[SystemFolder]cmd.exe" />
<CustomAction Id="RunCmd" ExeCommand="/c permission.cmd" />
<InstallExecuteSequence>
<Custom Action="CallCmd" After="InstallInitialize" />
<Custom Action="RunCmd" After="CallCmd" />
</InstallExecuteSequence>

Answer 5

La mayoría de las personas tienden a mantenerse al margen de la tabla lockPermissions ya que no es aditiva, lo que significa que sobrescribirá sus permisos actuales (desde una perspectiva del entorno administrado, esto es malo). Le sugiero que use una herramienta que admita la herencia de ACL , como SUBINACL o SETACL o una de las muchas herramientas de ACL.

En relación con el motivo por el cual tus publicaciones anteriores fallaron, hay algunas razones. Hay cuatro ubicaciones donde puede colocar sus acciones personalizadas (CA): UI, Inmediato, Deferido y Commit / Rollback.

Necesita que su CA establezca permisos en la secuencia diferida, porque los archivos no están presentes hasta la mitad de la secuencia diferida. Como tal, cualquier cosa anterior fallará.

1. Tu configuración es inmediata (por lo que fallará)
2. Su configuración está en la secuencia de 1 (que no se puede aplazar, por lo que fallará)

Necesita agregar un atributo de Execute="Deferred" y cambiar la secuencia de "1" a:

<Custom Action="CallCmd" Execute="Deferred" Before="InstallFinalize" />

Esto asegurará que se realice después de que se instalen los archivos, pero antes del final de la fase diferida (la ubicación deseada).

También sugiero que llame al archivo EXE directamente y no desde un archivo por lotes. El servicio de instalación se iniciará y el archivo EXE directamente en el contexto que necesite. El uso de un archivo por lotes iniciará el archivo por lotes en el contexto correcto y posiblemente perderá el contexto de una cuenta no deseada durante la ejecución.