WiX Bootstrapper структура проекта

Question

У нас есть продукт, похожий на Microsoft Office. Несколько различных приложений с большим количеством разделяемых библиотек. Мы пытаемся реорганизовать процесс развертывания этого продукта, поскольку в настоящее время мы используем несколько отдельных пакетов MSI для установки каждого приложения независимо. Хотя это работает, мы хотели бы использовать загрузчик WiX для объединения этих файлов MSI и создания только одного приложения настройки. В настоящее время все разделяемые библиотеки включены в каждый пакет MSI, что занимает много места.

У нас есть в основном два варианта для достижения этой цели:

• Создание проекта один установки WiX (MSI); включают все продукты как индивидуальные Особенности. В этом случае обработка разделяемых библиотек довольно прямо. Но структура проекта становится слишком большой , на мой взгляд.
• Создайте несколько пакетов MSI. Каждый из них имеет только один продукт и связывает их с загрузчиком. На мой взгляд, этот подход более гибкий и более четко организованный с точки зрения файлов и компонентов. Однако как работают общие библиотеки? Они не должны включаться в каждый файл MSI.

Какой подход предпочтительнее в проекте загрузки WiX?

Answer 1

Один большой MSI со многими функциями слишком сложно поддерживать.

Легко разделить компоненты между MSI. Общие компоненты должны иметь идентичные идентификаторы GUID и пути компонентов. См. details.

Для достижения этой цели создайте проект библиотеки WiX для всех общих компонентов (каждый компонент или группу компонентов в собственном фрагменте). Затем включите библиотеку во все проекты пакета WiX и обратитесь к ее компонентам (или группам компонентов) в проектах пакета WiX.

Answer 2

Вы можете объединить общие компоненты в несколько MSI, а затем создать один или несколько загрузочных файлов для ваших приложений.

несколько ключевых вещей, чтобы знать:

1. MsiPackages может быть настроен таким образом, когда загрузчик устанавливает MSI, она показывает или не показывает MsiPackage в разделе «Программы и компоненты» (ARP) списка.

2. MSI может иметь или иметь собственный пользовательский интерфейс. В любом случае вы можете подавить его в элементе MsiPackage. Если вам действительно нужно действительно спрашивать пользователей во время установки, вы можете запросить в приложении custome bootstrapper и, вероятно, передать его в MSI как MsiProperty.

Итак, я предлагаю MSI для каждого приложения и каждой группы общих компонентов. И один или несколько загрузочных файлов для одного или приложений MSI и общих MSI, которые им нужны. Если вы создаете пользовательский интерфейс custom bootstrapper application (C++ или .NET), например Visual Studio и WiX, ваши пользователи могут выборочно устанавливать/удалять различные приложения с помощью одного загрузочного устройства.