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

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

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

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

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

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

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

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

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

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