WIX/MSI CopyFile не работает при работе через SSH

Я построил простой файл MSI с WixTool 3.10.
Одной из функций является копирование файла, который уже существует на хосте.
Все работает нормально, когда я устанавливаю эту MSI через удаленный рабочий стол.
Однако, если я войду через SSH и запусту этот MSI, файл не будет скопирован.
Вот упрощенная версия моего файла wxs:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="my product" Language="1033" Version="1.0" Manufacturer="Allen" 
           UpgradeCode="PUT-GUID-HERE">
    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
    <MediaTemplate EmbedCab="yes" />

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="My Folder">
        </Directory>
      </Directory>
    </Directory>

    <Property Id="FILEA">
      <DirectorySearch Id="SearchSourceDir" Path="[SOURCEDIR]">
          <FileSearch Name="fileA.txt" />
      </DirectorySearch>
    </Property>

    <Component Id="cmpCopyFile" Guid="*" Directory="INSTALLFOLDER">
      <CopyFile Id="CopyFileA" SourceProperty="FILEA" DestinationProperty="INSTALLFOLDER"/>
    </Component>

    <Feature Id="FeatureCopyFile" Title="Copy file" Level="1">
      <ComponentRef Id="cmpCopyFile" />
    </Feature>
  </Product>
</Wix>

И вот команда, которую я использовал для установки:

msiexec /i test.msi /l*v install.log

Внутри журнала я вижу, что функция и компонент установлены, однако файл не получил копию.
Это ожидаемое поведение? Любая помощь или совет приветствуется.

Обновление: вот журналы для локальной и удаленной установки install_local.log install_remote.log

Источник

2 ответа

SecureCustomProperties: удаленная установка происходит без вывода сообщений, а клиентская - интерактивная? Это может повлиять на доступность APPSEARCH свойство в отложенном / тихом режиме.

Необходимо пометить свойства как защищенные, чтобы они передавались от клиента (GUI) к процессу сервера (Install). Не могли бы вы попробовать изменить это в исходном коде WiX и перекомпилировать:

Текущий:

<Property Id="FILEA">

Обновлено:

<Property Id="FILEA" Secure="yes">

Затем перекомпилируйте и протестируйте установку.

В качестве альтернативы вы можете изменить или "исправить" SecureCustomProperties свойство в вашем текущем файле MSI, чтобы включить FILEA, Это включает в себя префикс текущего значения для SecureCustomProperties с FILEA вдоль этих линий:

FILEA;NETFRAMEWORK20;WIX_DOWNGRADE_DETECTED;WIX_UPGRADE_DETECTED

Если вы перекомпилируете MSI из источника WiX, это будет сделано за вас - очевидно. Добавление этого в случае, если источник не скомпилируется с указанным атрибутом Secured.

Кроме того, это выглядит странно из локального файла журнала:

PROPERTY CHANGE: Adding FILEA property. Its value is 'C:\Users\tetter\fileA.txt\'.

Но давайте посмотрим, решит ли вышеизложенное проблему.

Избегать копирования файлов?: Какой SSH клиент? Никогда не пытался развернуть MSI через SSH. Не совпадает на 100%, но, возможно, прочитайте мой ответ на вопрос о файлах конфигурации и управления настройками. Скорее всего, было бы более надежно установить файл более надежными средствами - как вы можете ясно видеть из текущих проблем. Например, используя таблицу IniFile или используя возможности записи XML в WiX.

Загрузка приложения. Если честно, почему бы не загрузить эти параметры из базы данных или из UNC-пути непосредственно из приложения? Это избавит вас от любых проблем развертывания, и у вас появятся лучшие возможности отладки (отладка в реальном времени на тестовых компьютерах, нет проблем "единократного" развертывания с ограниченной возможностью отладки для расследования), и вы сможете убедиться, что на всех клиентах установлены самые последние версии. настройки при условии, что они могут получить доступ к пути UNC? Просто идея.

Причина. Если бы я стал теоретизировать причину, я бы сказал, что ваш MSI работает в контексте вашего администратора через удаленный рабочий стол с доступом к вашему контексту входа и токену доступа и, следовательно, имеет права на общий ресурс. Когда вы запускаете MSI из SSH, он может работать в системном контексте, вообще без доступа к сети - или очень ограниченный. Просто предположение.

Источник

Это может иметь значение, если вы используете правильное имя для чувствительного к регистру свойства источника, которое является SourceDir

https://msdn.microsoft.com/en-us/library/windows/desktop/aa371857(v=vs.85).aspx

Источник
Другие вопросы по тегам