Блог

У меня есть два установщика 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? Разрешено ли это вообще? Как я могу этого добиться?

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

Случай 1: Code X переносится между библиотеками DLL, например, A устанавливает a.dll ; B устанавливает b.dll , и код перемещается из b.dll чтобы a.dll

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

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

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

Случай 2: dll Code X мигрирует между установщиками, например, B устанавливает c.dll , и эта библиотека dll теперь вместо этого будет установлена

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

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

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