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

Question

Pregunta de Wii novato: ¿Cómo puedo
? 1. Copie un script de shell de un solo uso a la temperatura junto con el instalador
p.

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

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

<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 permissions.cmd para ejecutarlo - ¿necesito [TEMPDIR] permissions.cmd o algo?
• Mi Secuencia llega demasiado pronto, antes de instalar el programa.
• Necesito cmd/c permissions.cmd en algún lugar de aquí, probablemente cerca de ExeCommand?

En este ejemplo permissions.cmd utiliza cacls.exe para agregar el usuario interactivo con permisos de escritura al % Archivos de programa% \ Vendor ACL. También podría utilizar secureObject - esa pregunta es "How do I add the interactive user to a directory in a localized Windows"?

Answer 1

encontré la entrada de blog From MSI to WiX, Part 5 - Custom actions: Introduction útil cuando se quería entender CustomActions en WiX.

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

que tiene 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 2

En lugar de ejecutar una acción personalizada que puede intentar usar Permission element como hijo 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 sobrescribir o solo edite la ACL de la carpeta?

Según MSDN documentation sobrescribe:

Cada archivo, clave de registro, o directorio que se muestra en la Tabla LockPermissions recibe un descriptor de seguridad explícita, si se sustituye un objeto existente o no.

simplemente me confirmó que mediante la ejecución de la instalación de prueba en Windows 2000.

Answer 3

¿Tiene usted un ejemplo de cómo se usa?Quiero decir, ¿usar CreateFolder anidados bajo el directorio cuya ACL quiero cambiar? ¿O utilizo primero CreateFolder, 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 4

La mayoría de la gente tiende a alejarse de la mesa LockPermissions ya que no es aditivo, lo que significa que se sobreponen a sus permisos actuales (desde una perspectiva entorno administrado, esto es malo). Le sugiero que use una herramienta que admita la herencia ACL, como SUBINACL o SETACL o una de las muchas herramientas de ACL.

En relación con por qué fallaron sus publicaciones anteriores, 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. Su configuración está en inmediata (por lo que se producirá un error)
2. Su configuración se encuentra en la secuencia de 1 (lo cual no es posible aplazar por lo que se producirá un error)

Es necesario añadir un atributo de Execute="Deferred" y la secuencia de cambio de "1" a:

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

Esto asegurará que se hace después de que se instalan los archivos, pero antes del final de la fase diferido (la l deseado ocación).

También le 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.

Answer 5

Aquí está un ejemplo de trabajo (para la configuración de permisos, no para la ejecución de 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 es usar 'Extended = 'Sí'' en la etiqueta del permiso, por lo que se trata de utilizar la tabla SecureObjects y acción personalizada, no la tabla LockPermissions (ver WiX docs for Permission Element). 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.