Зависимости в установщике MS / Wix
Я в настоящее время изучаю капризы WiX и установщика Windows, и я поразил камень преткновения.
Проект, что я являюсь в настоящее время упаковочным, составлен из шести дискретных блоков. На данный момент давайте назовем их A, B, C, D, E, и F.
Блок A является рядом общих библиотек и утилит, которые используются любым проектом. Это не представляет функциональности конечного пользователя.
Блок B является другим набором общих библиотек и утилит, которые требуют функциональности, обеспеченной Блоком A. Это кажется нечетным, но архитектура вне моей способности влиять или управлять.
Блок 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 Installer при обновлении.
Другая мысль, что я имел, состояла в том, чтобы сделать единственный установщик для A, B, и C и потребовать его в установщиках для D, E, и F через ComponentSearch.
Любая идея имеет смысл? Если никакая идея не имеет смысл, у Вас есть какие-либо рекомендации для корректного способа сделать это?
2 ответа
Включите A + B + C в каждый установщик и установите в общие файлы. Установщик Windows будет обрабатывать подсчет ссылок, так что на диске будет существовать только одна копия, и она останется до удаления последнего продукта. Обновление будет в порядке, установщик Windows предназначен для такого рода вещей :)
Однако вместо слияния модулей я предлагаю использовать Wixlibs
Меня заверили, что куски A, B и C сохранят стабильную API-интерфейсы, чтобы их можно было обновить без нарушения функциональности D, E,
введите здесь кодили F.
Стабильного API может быть недостаточно. Что, если приложение случайно полагается на поведение, которое является недокументированным совпадением (например, порядок элементов в возвращаемом списке) или, что еще хуже, на поведение, которое на самом деле является ошибкой? Обновление общих компонентов может привести к поломке вашего приложения, поскольку оно не было протестировано на обновленных компонентах.
Моя немедленная мысль - создать объединить модули ... Я боюсь, что это вызвать проблемы внутри Windows Installer validation when upgrading.
You may be right that there are serviceability issues with merge modules. Microsoft no longer distributes new merge modules themselves. It is also notoriously difficult to create upgradeable components and still follow the Windows Installer Component Rules.
I prefer to actually install "shared" components into each application's bin folder separately. I do create wixlibs for these components, so that they can be shared between the application installers. Inside the wixlib files, I put the component in a As a result, the applications have their dependencies in their own bin folder and remain isolated from each other. There is a trade-off of course: Со сборками .NET ситуация может стать еще более сложной с GAC , строгими именами , перенаправлением файлов политики и т. д. этот пост уже идет слишком долго :-)