В настоящее время мы обновляем наши скрипты сборки с 3.0 до 3.5 и попутно исправляем кучу старых ошибок ICE. Я прочитал ряд статей, но я немного сбит с толку относительно того, что обычно является лучшим подходом к использованию сопутствующих файлов.
Теперь, если предположить, что файл A.manifest является сопутствующим файлом для A.exe...
Изначально: наша старая сборка разбивает 2 файла на 2 компонента:
<Component Guid="*" Id="A.exe" SharedDllRefCount="yes">
<File Id="..." KeyPath="yes" Source="A.exe"/>
</Component>
<Component Guid="*" Id="A.exe.manifest" SharedDllRefCount="yes">
<File CompanionFile="A.exe" Id="..." Source="A.exe.manifest"/>
</Component>
Что вызывает ICE54: ПРЕДУПРЕЖДЕНИЕ. Компонент «A.exe.manifest» использует файл «A.exe.manifest» в качестве KeyPath, но версия файла предоставляется файлом «A.exe», поэтому я думаю, это явно неправильно.
1-й подход: поэтому я попытался добавить KeyPath=yes в каталог компаньона:
<Component .../>
<Component Guid="*" Id="A.exe.manifest" SharedDllRefCount="yes" KeyPath="yes">
<File CompanionFile="A.exe" Id="..." Source="A.exe.manifest"/>
</Component>
Это подавляет предупреждение, но в Orca столбец KeyPath компонента отображается как пустой, поэтому я сомневаюсь, что это правильно?
2-й подход: затем я попытался объединить компоненты:
<Component Guid="*" Id="A.exe" SharedDllRefCount="yes"> <!-- GUID is wrong! -->
<File Id="..." KeyPath="yes" Source="A.exe"/>
<File CompanionFile="A.exe" Id="..." Source="A.exe.manifest"/>
</Component>
Но похоже, что позволить WiX автоматически генерировать GUID здесь не получится. Но если бы я генерировал идентификаторы GUID вручную, каждый раз, когда мы собирали бы его, это нарушало бы правила компонентов при обновлении! На самом деле мы развертываем множество сопутствующих файлов, поэтому создание хэша каждого компонента и его постоянное хранение также может оказаться невозможным. То же самое для использования фиктивного ключа реестра для каждого сопутствующего файла.
TLDR: какой из двух подходов лучше всего подходит для WiX?
