Как запустить скрипт в WiX с пользовательским действием — самый простой пример?

Вопрос новичка в WiX: как мне
1. Скопируйте одноразовый сценарий оболочки во временную папку вместе с установщиком
, например.

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

2. Найдите и запустите этот скрипт в конце установки.
например.

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

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

Я думаю, что у меня как минимум три проблемы:

  • Я не могу найти файл permissions.cmd для его запуска. Мне нужен файл [TEMPDIR]permissions.cmd или что-то в этом роде?
  • Моя последовательность появляется слишком рано, до того, как программа будет установлена.
  • Мне нужно cmd /c разрешения.cmd где-то здесь, возможно, рядом с ExeCommand?

В этом примере permissions.cmd использует cacls.exe для добавления интерактивного пользователя с разрешениями на запись в список управления доступом %ProgramFiles%\Vendor. Я также мог бы использовать secureObject — этот вопрос "Как добавить интерактивного пользователя в каталог в локализованной Windows"?


installation windows-installer wix
person nray    schedule 04.10.2008    source источник

Ответы (5)


arrow_upward
5
arrow_downward

Вот рабочий пример (для установки разрешений, а не для запуска скрипта):

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

Обратите внимание, что здесь используется «Extended="Yes"' в теге Permission, поэтому используется таблица SecureObjects и настраиваемое действие, а не таблица LockPermissions (см. Документы WiX для элемента разрешений). В этом примере разрешения, применяемые SecureObjects к каталогу MyProd, наследуются подкаталогами, что не имеет места при использовании LockPermissions.

person user14402    schedule 06.01.2009

arrow_upward
5
arrow_downward

Я нашел сообщение в блоге От MSI до WiX, часть 5. Пользовательские действия: введение было полезно, когда я хотел понять CustomActions в WiX.

Вы также можете найти определение CustomAction и его атрибутов в CustomAction Element.

Вам нужно сделать что-то вроде этого

<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>
person CheGueVerra    schedule 04.10.2008

arrow_upward
2
arrow_downward

У вас есть пример того, как это используется? Я имею в виду, использовать ли CreateFolder, вложенный в каталог, ACL которого я хочу изменить? Или сначала отдельно использовать CreateFolder? Следующее даже близко?

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

person nray    schedule 14.10.2008
comment
Ваш пример выглядит правильно. Элемент CreateFolder является дочерним элементом элемента Component, который, в свою очередь, является дочерним элементом элемента Directory. Разрешения будут установлены для этого каталога. - person Pavel Chuchuva; 15.10.2008

arrow_upward
2
arrow_downward

Вместо запуска настраиваемого действия вы можете попробовать использовать элемент Permission в качестве дочернего элемента CreateFolder. элемент, например:

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

Это перезаписывает или просто редактирует ACL папки?

Согласно документации MSDN, он перезаписывает:

Каждый файл, раздел реестра или каталог, перечисленные в таблице LockPermissions, получает явный дескриптор безопасности, независимо от того, заменяет ли он существующий объект или нет.

Я только что подтвердил это, запустив тестовую установку в Windows 2000.

person Pavel Chuchuva    schedule 13.10.2008

arrow_upward
1
arrow_downward

Большинство людей стараются держаться подальше от таблицы lockPermissions, поскольку она не является аддитивной, то есть перезаписывает ваши текущие разрешения (с точки зрения управляемой среды это плохо). Я бы посоветовал вам использовать инструмент, который поддерживает наследование ACL, например SUBINACL или SETACL, или один из многие инструменты ACL.

Что касается того, почему ваши предыдущие сообщения не увенчались успехом, есть несколько причин. Есть четыре места, где вы можете разместить свои настраиваемые действия (CA): пользовательский интерфейс, немедленное, отложенное и фиксация/откат.

Вам нужен ЦС для установки разрешений в отложенной последовательности, потому что файлы не будут доступны до середины отложенной последовательности. Таким образом, все, что было раньше, потерпит неудачу.

  1. Ваша настройка выполняется немедленно (поэтому произойдет сбой)
  2. Ваша настройка находится в последовательности 1 (что невозможно отложить, поэтому произойдет сбой)

Вам нужно добавить атрибут Execute="Deferred" и изменить последовательность с "1" на:

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

Это гарантирует, что это будет сделано после установки файлов, но до окончания отложенной фазы (желаемое место).

Я также предлагаю вам вызывать EXE-файл напрямую, а не из пакетного файла. Запустится служба установщика и EXE-файл прямо в нужном вам контексте. Использование пакетного файла запустит пакетный файл в правильном контексте и потенциально может потерять контекст для нежелательной учетной записи во время выполнения.

person Community    schedule 23.10.2008