msi удаление файлов вместо их замены

Question

У меня есть установщик .msi, который помещает несколько файлов. После обновления версии файлы получили новые идентификаторы GUID, и теперь при обновлении с версии 1 до 2 установщик удаляет некоторые из этих файлов вместо их обновления.

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

File: <PATH_TO_FILE>; Overwrite; Won't patch; Existing file is unversioned and unmodified - hash doesn't match source file

Как мне обеспечить, чтобы файлы с новыми GUID копировались поверх более старых версий (сделать их версионными)?

UPDATE:

Я попытался установить ReinstallMode в «amus», а не «omus», но похоже, что поскольку предыдущий .msi был «omus», файлы все равно исчезают, если я не запускаю новый установщик дважды подряд, что не оптимально.

По сути, мне нужен установщик версии 3, который может обновить версию 1 или 2 и не удалять соответствующие файлы (если это возможно)

Answer 1

Быстрое исправление : я добавил этот сводный раздел вверху, но, пожалуйста, прочтите также разделы с подробностями ниже. Вы испытываете общую проблему испортил подсчет ссылок на компоненты , и это вызывая эти проблемы обновления, которые вы видите. Идентификаторы GUID компонента остаются стабильными во всех выпусках, пока путь ключа не меняется (и это никогда не должно меняться - если это так, то вам нужен новый компонент GUID - пояснение ниже).

Ранний REP : Вместо того, чтобы исправить реальную проблему, мог бы быть способ справиться с ней, который не идеален, и который должен использовать «Early REP», как мы его называем. По сути вы двигаетесь RemoveExistingProducts в InstallExecuteSequence до InstallInitialize. Это полностью удалит старый версия, а затем установить новую со всеми ее файлами (как правило) - без помех. Вы отделяете новую версию от прошлых грехов. Это можно сделать с помощью Orca или аналогичного бесплатного инструмента (внизу) для исправления вашего скомпилированный MSI (изменить порядковый номер в таблице InstallExecuteSequence) или это можно сделать в исходных файлах - в зависимости от того, какой инструмент вы используете.

---

Подсчет ссылок компонентов : Ошибочные GUID компонентов и, следовательно, подсчет ссылок для компонентов MSI - очень плохая вещь - это надо сказать. The component / key path concept лежит в основе самой MSI - как она занимается обновлением файлов, обслуживанием и подсчетом ссылок. The concept is essentially that for every absolute key-path there is supposed to be a single component GUID, shared by all packages targeting that location. Здесь есть еще несколько деталей: Изменить GUID моего компонента в wix?

Идентификаторы GUID для автокомпонентов WiX : If you are using WiX (чего мы не знаем, если вы это сделаете), тогда я бы предложил вам использовать WiX's auto-GUID concept, в результате чего GUID компонента рассчитывается на основе пути к ключу установки, а не жестко кодируется в вашем источнике WiX (или генерируется процессом сборки). Этот алгоритм WiX позаботится о подсчете ссылок в «автоматическом режиме».

Этот ответ пытается объяснить причину, стоящую за GUID автокомпонентов WiX, и какую пользу это может принести вам: Синтаксис для направляющих в WIX? Не все места установки позволяют использовать GUID компонентов генерируется автоматически, но по большей части это всеобъемлющее «авто-волшебство».

Пример кода : При использовании GUID автокомпонента вы не указываете GUID в своем источнике:

<!-- Sample guid below, do not copy paste -->
<Component Id="File.dll" Guid="{12345678-1234-1234-1234-123456789ABC}">
  <File Id="File.dll" Name="File.dll" KeyPath="yes" Source="..\File.dll" />
</Component>

в сравнении с GUID автокомпонента:

<Component>
  <File Source="..\File.dll" />
</Component>