Зависимости в MS Installer / Wix

Question

В настоящее время я изучаю капризы установщика WiX и Windows и наткнулся на камень преткновения.

Проект, который я сейчас упаковываю, состоит из шести отдельных кусков. А пока давайте назовем их A, B, C, D, E и F.

Chunk A - это набор общих библиотек и утилит, которые используются в любом другом проекте. Это не представляет никакой функциональности конечного пользователя.

Chunk B - это еще один набор общих библиотек и утилит, которым требуется функциональность, предоставляемая Chunk A. Это кажется странным, но архитектура находится за пределами моей способности влиять или контролировать.

Chunk C - это третий набор общих библиотек и утилит, которым требуется функциональность, предоставляемая блоками A и B. Это кажется еще более странным, чем раньше, но я все еще не могу изменить это.

Для блоков D, E и F требуется функциональность, предоставляемая фрагментами A, B и C.

Если возможно, я хотел бы убедиться, что есть только одна установка блоков A, B и C, которые совместно используются для установок D, E и F. Мне дали гарантию, что блоки A , B и C сохранят стабильные API, чтобы их можно было обновлять, не нарушая функциональность D, E или F.

Моя непосредственная мысль - создать модули слияния для компонентов в A, B и C, а затем ссылаться на них в функциях, предоставляемых отдельными установщиками для D, E и F. Это приведет к тому, что установщики будут раздуты, но это будет гарантировать, что необходимые компоненты установлены. К сожалению, я боюсь, что это вызовет проблемы при проверке установщика Windows при обновлении.

Еще одна мысль, которая у меня возникла, состояла в том, чтобы создать единый установщик для A, B и C и потребовать его в установщиках для D, E и F через поиск компонентов.

Имеет ли какая-либо идея смысл? Если ни одна из идей не имеет смысла, есть ли у вас какие-либо рекомендации относительно правильного способа сделать это?

Answer 1

Включите A + B + C в каждый установщик и установите в общие файлы. Установщик Windows будет обрабатывать подсчет ссылок, чтобы на диске существовала только одна копия, и она оставалась до тех пор, пока не будет удален последний продукт. Обновление будет в порядке, установщик Windows предназначен для такого рода вещей:)

Однако вместо модулей слияния я предлагаю использовать Wixlibs

Answer 2

Мне дали заверение, что куски A, B и C сохранят стабильность API, чтобы они могли быть обновлены не нарушая функциональность D, E, enter code here или F.

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

Моя ближайшая мысль - создать объединить модули ... боюсь, что это будет вызвать проблемы внутри Windows Проверка установщика при обновлении.

Возможно, вы правы, что существуют проблемы с исправностью модулей слияния. Microsoft больше не распространяет новые модули слияния. Общеизвестно, что создавать обновляемые компоненты также сложно, и при этом они по-прежнему соблюдают Правила для компонентов установщика Windows .

Я предпочитаю устанавливать «общие» компоненты в папку bin каждого приложения отдельно. Я создаю wixlibs для этих компонентов, чтобы они могли быть общими для установщиков приложений. Внутри файлов wixlib я поместил компонент в <DirectoryRef Id="SharedComponentFolder>. Эта ссылка на каталог оставлена ​​неопределенной, что не является проблемой для lit.exe. В установщиках приложений я затем называю папку bin приложения следующим образом:

<Directory Id="AppBinFolder" Name="bin">
   <Directory Id="SharedComponent1Folder" /> <!-- alias for AppBinFolder -->
   <Directory Id="SharedComponent2Folder" /> <!-- another alias -->
</Directory>

В результате приложения имеют свои зависимости в своей папке bin и остаются изолированными друг от друга. Конечно, есть компромисс:

• вы получаете стабильность, потому что ваше приложение всегда работает с точной версией зависимостей, с которыми оно проверяется; DLL Hell проблем.
• у вас больше работы при обновлении общего компонента; каждый установщик приложения должен быть обновлен и распространен, а не только один установщик для общего компонента.
• вы теряете место на диске (потому что общие компоненты установлены несколько раз).

С сборками .NET история может стать еще более сложной с GAC , строгими именами , , перенаправляет файл политики и т. Д. Но этот пост уже работает слишком долго :-)