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

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

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

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

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

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

Необходимо сделать что-то вроде этого

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

Вы получили пример того, как это используется? Я имею в виду, действительно используйте 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>

Вместо того, чтобы выполнять пользовательское действие, можно попытаться использовать элемент Разрешения в качестве ребенка элемента 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.

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

Относительно того, почему Ваши более ранние сообщения, отказавшие там, несколько причин. Существует четыре места, куда можно поместить пользовательские действия (АВАРИЯ): UI, Непосредственный, Задержанный, и Фиксация/Откат.

Вам нужен Ваш CA для установки полномочий в задержанной последовательности, потому что файлы не присутствуют до на полпути через задержанную последовательность. По сути, что-либо предшествующее перестанет работать.

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

Необходимо добавить атрибут Execute="Deferred" и изменение упорядочивает от "1" до:

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

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

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