Несколько установщиков MSI, устанавливающих один и тот же каталог

Question

У меня есть два установщика MSI, один для продукта A, построенный с помощью InstallShield, и один для продукта B, построенного с помощью WiX. Продукт B должен был работать поверх продукта A, но в последнее время некоторый код X был перенесен с B на A.

На новой установке проблем не возникает. Однако предположим, что на сервере у меня установлены A.1 и B.1 (.1 = версия 1), где X установлен через B. И давайте предположим, что я хочу установить A.2, который теперь содержит X.

Будет ли обновлен код X? Что произойдет, если я попытаюсь удалить A.2 или B.1? Это разрешено вообще? Как я могу это достичь?

Answer 1

Это во многом зависит от нескольких вещей, которые вы не указали очень четко, поэтому давайте немного погрузимся в него. Я предполагаю, что с версии 1 все файлы уникальны между установщиками или правильно распределены и не имеют отношения к коду, о котором вы говорите о миграции (поэтому его можно игнорировать).

Дело 1: Код X переносится между DLL, например. A устанавливает a.dll; B устанавливает b.dll, а код переходит из b.dll в a.dll.

В этом случае, если между двумя продуктами нет цепочек вызовов, у вас нет ничего особенного. Просто замените a.dll на A.2 следующей версией, а B.2 замените b.dll на следующую версию. Нет никаких проблем в отношении порядка установки или множественного владения DLL.

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

Если есть опубликованный интерфейс (например, класс COM), тогда для обновления может потребоваться обязательный заказ для обеспечения того, чтобы b.dll отказался от регистрационной справки до того, как файл a.dll ее принял, однако эти изменения нарушают компонент правила.

Корпус 2: Идентификатор dll X-кода X изменяется между установщиками, например. B устанавливает c.dll, и теперь эта dll будет установлена ​​на A

В этом случае ваш успех будет зависеть от качества вашего первоначального авторства. Если c.dll установлен собственным компонентом и помечен как общий, вы можете добавить этот компонент в A (соответствующий его настройкам), и обновление будет работать плавно в любом порядке. Если вы сначала установите A.2, он добавит к счетчику ссылок, поэтому включение B.2 не будет отменено, но не удалит его. Если вы сначала установите B.2, он временно удалит c.dll, но установка A.2 восстановит его. Деинсталляция будет работать аналогичным образом, отслеживать подсчет ссылок и удалять по мере необходимости.

Но это предполагает серьезное обновление. Если вы используете небольшое обновление (поставляется ли как .msp или .msi), вы находитесь в гораздо более сложном сценарии. Чтобы путь обновления B был чистым, он должен поддерживать компонент c.dll и выбирать альтернативный подход для удаления c.dll. Однако все подходы, о которых я знаю, конфликтуют с A, устанавливая точную копию одного и того же компонента в одном месте. В этом случае установка B.2 сначала должна работать, но при установке второй может удалить c.dll.

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