Подсчет ссылок MSI: два продукта устанавливают одни и те же MSI

Когда продукты A и B устанавливают несколько MSI, а некоторые из MSI одинаковы, удаляет ли A или B другое? Имеет ли место размещения местоположение?

Также, что происходит, когда обычная версия MSI C выше в продуктах B и B обновляет C при установке? Теперь удаление B удалит общий MSI C, который разбивает Продукт A. Как вы справляетесь с этим изящно, не используя флаг Permanent?

ОТВЕТЫ

Ответ 1

Первое, что приходит в голову с этим вопросом, состоит в том, разлагаются ли эти продукты так, как они должны быть.

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

В этом правиле есть некоторые квалификации:

  • Если компонент отмечен постоянный, он никогда не удаляется
  • Если файл/элемент реестра имеет отсутствие компонента GUID вообще, он устанавливается, никогда не отслеживается установщиком Windows и не будет удалён либо
  • Наконец, подсчет ссылок для MSI позволяет одному и тому же компоненту делиться между несколькими продуктами, и он будет сохраняться на диске во время удаления, если он зарегистрирован в использовании несколькими другими пакетами установщика.

Механизмы для создания общих компонентов между пакетами MSI обычно:

  • Объединить модули позволяют устанавливать общие компоненты, которые подсчитываются по ссылке, и которые останутся на диске после удаления связанного продукта, если есть другие клиенты, использующие GUID в системе. Модуль слияния объединяется в другие пакеты MSI во время компиляции. Форма двоичного раннего связывания, если хотите. Его можно объединить в любой пакет.
  • С появлением Wix (исходных файлов установщика на основе xml) можно включить один и тот же сегмент файлов из несколько установок с помощью источника XML включают файл вместо модуля слияния. На мой взгляд, это значительно превосходит, потому что Wix лучше работает для контроля источника (см. Ссылку Wix для объяснения). Важно понять, что " источник Wix включает файл" имеет тот же самый эффект, что и модуль слияния - его компоненты правильно подсчитываются ссылкой для совместного использования между различными пакетами установщика, при условии, что идентификаторы GUID в исходном файле жестко закодированы (я рекомендую не использовать автогенераторы для этой конкретной цели). Мое личное мнение, что вы должны использовать сторонние модули слияния для общих файлов времени выполнения, но только Wix включает в себя ваши собственные общие файлы. Объединить модули сложнее, чем Wix включает imho.

Обновление и замена файла:

  • Что касается сценариев обновления, правила замены файлов MSI позаботится об обновлении новых файлов в зависимости от общего параметра в специальном установщике Windows свойство REINSTALLMODE.
  • В общем случае файлы с более высокой версией перезаписывают файлы с более низкой версией. Файлы, не поддерживающие версию, перезаписываются, если они не изменены. Если они изменены, создание и изменение штампов даты различны, и файл остается один.
  • Имейте в виду, что проблема понижения файлов активно обескураживается общим дизайном MSI. Если вам нужно понизить файлы (общие или нет), в вашем дизайне есть что-то развертывание smelly.

В этот момент я бы полностью прочитал эти ответы:

Если вы используете Wix или хотите использовать Wix, я бы подумал, что лучший способ справиться с вашими перекрывающимися продуктами - разложить ваш установщик на исходные файлы сегмента Wix, которые вы включаете в качестве необходимых в ваших основных установщиках. Это позволит удалить один продукт, чтобы оставить на месте любые компоненты, используемые другими приложениями.

С учетом сказанного, я не люблю вызывать слишком много перекрывающихся зависимостей в установщиках по причинам, перечисленным в этой статье (также перечисленным выше): Wix для установки нескольких приложений.

Для стабильности крайне важно, чтобы общие компоненты были стабильными, прежде чем использовать слишком много настроек как исправление ошибки как общее правило потребует перекомпиляции всех настроек, с которыми компилируется или объединяется общий компонент. Легкий способ сказать это: объединить файлы вместе, которые меняются вместе.

Чтобы противостоять этой потребности в массовой перекомпиляции, вы можете выбрать автономную поддерживающую настройку, состоящую из некоторых общих компонентов. Один или несколько таких " общих компонентов установки", которые, вероятно, содержат Wix, включают в себя изменения вместе в аналогичном, медленном расписании расписания, а затем разделить настройки для каждого продукта должны учитывать любые потребности развертывания при сохранении баланса между ремонтопригодностью и гибкостью.

Настройка продукта должна быть той, которая часто перекомпилируется, а настройки разделяемых модулей должны быть предназначены для минимальной перекомпиляции. Затем дождитесь изменения требований: -).

Для меня это все о связности и > , а также сложности балансирования продаж, маркетинга и технических потребностей.

Ответ 2

Если продукт A и продукт B имеют MSI C, то Если установлен продукт A, также установлен MSI C, теперь, когда установлен продукт B, MSI C не будет установлен, поскольку он уже доступен в системе (если продукт B основан на WiX Burn, он регистрирует зависимость). В случае деинсталляции подсчет ссылок автоматически обрабатывается, если Продукт А и Продукт В являются установщиком на основе WiX Burn или любым другим Bootstrapper, который поддерживает подсчет ссылок, а MSI C удаляется вместе с Продуктом B.

Ответ 3

даже я искал ответ на вышеупомянутый вопрос, но в Wix v3.7 и выше пакеты MSI автоматически ссылаются на счет двигателя Burn. Я проверил это и отлично работает. То же самое можно проверить в Rob blog