Comment exécuter un script dans WiX avec une action personnalisée - exemple le plus simple possible?

Question

Débutant Question WiX: Comment faire
1. Copiez un script shell à usage unique sur temp avec le programme d'installation
par exemple.

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

2. Recherchez et exécutez ce script à la fin de l'installation.
par exemple.

<CustomAction Id='SetFolderPermissions' BinaryKey='permissions.cmd' 
    ExeCommand='permissions.cmd' Return='ignore'/> 

<InstallExecuteSequence> 
    <Custom Action="SetFolderPermissions" Sequence='1'/> 
</InstallExecuteSequence> 

Je crois avoir au moins trois problèmes:

• Je ne peux pas trouver permissions.cmd pour l'exécuter - dois-je [TEMPDIR] permissions.cmd ou quelque chose?
• Mon La séquence arrive trop tôt, avant l'installation du programme.
• J'ai besoin cmd/c permissions.cmd quelque part ici, probablement près de ExeCommand?

Dans cet exemple permissions.cmd utilise cacls.exe pour ajouter l'utilisateur interactif avec des autorisations d'écriture sur le % ProgramFiles% \ fournisseur ACL. Je pourrais aussi utiliser secureObject - cette question est "How do I add the interactive user to a directory in a localized Windows"?

Answer 1

J'ai trouvé le billet de blog From MSI to WiX, Part 5 - Custom actions: Introduction utile quand je voulais comprendre CustomActions dans WiX. Vous pouvez également trouver la définition de CustomAction et ses attributs dans CustomAction Element.

Vous devez faire quelque chose comme ça

<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

Plutôt que de courir l'action personnalisée que vous pouvez essayer d'utiliser Permission element comme un enfant de l'élément CreateFolder, par exemple:

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

Est-ce écrasera ou suffit d'éditer l'ACL du dossier?

Selon MSDN documentation elle écrasera:

Chaque fichier, clé de registre, ou un répertoire qui est répertorié dans la LockPermissions Table reçoit un descripteur de sécurité explicite, si elle remplace un objet existant ou non.

Je viens de confirmer que l'installation en exécutant de test sur Windows 2000.

Answer 3

Avez-vous un exemple de la façon dont il est utilisé?Je veux dire, utilisez CreateFolder imbriqué sous le répertoire dont je veux changer la liste de contrôle d'accès? Ou dois-je utiliser CreateFolder en premier, séparément? Est-ce que ce qui suit est proche?

<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 plupart des gens ont tendance à se démarquer de la table LockPermissions comme il est additif, ce qui signifie qu'il écrasera vos autorisations actuelles (à partir d'un environnement géré perspective, cela est mauvais). Je vous suggère d'utiliser un outil qui prend en charge l'héritage ACL tel que SUBINACL ou SETACL ou l'un des nombreux outils ACL.

En ce qui concerne la raison pour laquelle vos messages précédents ont échoué, il existe plusieurs raisons. Vous pouvez placer vos actions personnalisées (CA) dans quatre emplacements: interface utilisateur, exécution immédiate, différée et validation/restauration.

Vous avez besoin de votre autorité de certification pour définir des autorisations dans la séquence différée, car les fichiers ne sont pas présents jusqu'à la moitié de la séquence différée. En tant que tel, tout ce qui précède échouera.

1. Votre configuration est immédiate (donc échouera)
2. Votre configuration est à la séquence de 1 (qui est pas possible d'être différée pour échouera)

Vous devez ajouter un attribut de Execute="Deferred" et la séquence de changement de « 1 » à:

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

Cela permettra d'assurer qu'il est fait après que les fichiers sont installés, mais avant la fin de la phase différée (la l désirée ocation).

Je vous suggère également d'appeler le fichier EXE directement et non à partir d'un fichier batch. Le service d'installation va démarrer et le fichier EXE directement dans le contexte dont vous avez besoin. L'utilisation d'un fichier batch lancera le fichier de commandes dans le bon contexte et risque de perdre le contexte d'un compte indésirable lors de l'exécution.

Answer 5

Voici un exemple de travail (pour définir des autorisations, pas pour l'exécution d'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> 

Notez que cela est d'utiliser « Extended = « Oui » » dans la balise d'autorisation, de sorte qu'il utilise la table SecureObjects et l'action personnalisée n'est pas la table LockPermissions (voir WiX docs for Permission Element). Dans cet exemple, les autorisations appliquées au répertoire MyProd par SecureObjects sont héritées par des sous-répertoires, ce qui n'est pas le cas lorsque LockPermissions est utilisé.