WiX - VC++ Runtime - vcredist vs merge module

Question

Я строю установщик MSI с помощью WiX. Поскольку для продукта, который должен быть установлен, требуется среда выполнения VC++, я нашел два варианта: (a) использование соответствующего модуля слияния и (b) использование записи для запуска vcredist до MSI фактического продукта. Чтобы различать эти два варианта, у меня есть некоторые вопросы, на которые я не нашел информацию.

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

1.1) Если в системе присутствует установка vcredist, я полагаю, что модуль слияния ничего не делает во время установки продукта?

1.2) Если была установлена ​​установка vcredist, как указано в 1.1), что произойдет, если пользователь просто удалит эту среду выполнения с помощью добавления и удаления программ? Я полагаю, что продукт больше не работает (по крайней мере, до тех пор, пока не будет выполнена ремонтная установка, из-за чего материал в модуле слияния в MSI повторно добавляет необходимые файлы?)

1.3) Если vcredist еще не установлен, и Установщик MSI копирует файлы в систему, а после этого другой установщик или пользователь вызывает vcredist.exe, что происходит тогда? Vcredist сообщает, что среда выполнения уже установлена?

1.4) Если удаление продукта - это файлы, скопированные в систему с удалением модуля слияния?

1.5) Если ответ на вопрос 1.4) да (удалены файлы времени исполнения VC++): если в системе установлены два разных продукта, как с использованием одного и того же модуля слияния внутри, и один из двух продуктов удаляется, что происходит с установленные файлы времени выполнения? Удаляются ли они, а другой продукт больше не работает из-за недостающих файлов времени выполнения?

Заранее за вашу помощь и информацию.

С уважением, Гуннар

Answer 1

модуль слияния просто последовательный способ установки (обычно совместно) должным образом файлы, включив их в строй. Как аналогия, компиляторы C++ строят файлы .obj, которые объединены в exe, но вы больше не можете говорить об объекте, имеющем отдельное существование после того, как exe будет построен и запущен. То же самое происходит с модулями слияния. Как только они находятся в MSI, они просто файлы для установки, и они следуют стандартным правилам. Если файл уже установлен (в общем местоположении), он будет перезаписан, если входящая версия будет выше, чем уже установленная версия. Его содержащий компонент будет ref подсчитан одним, и удаление других продуктов (включая VC redist) с использованием компонента будет обратным отсчетом, чтобы любые продукты, использующие этот файл, не прерывались - для них все еще существует версия. Это всего лишь стандартный метод совместного доступа к файлам, совместно используемым среди продуктов, и не имеет значения, что один продукт является перекрестком VC, а другой - вашим MSI. Так же легко было бы быть несколькими из ваших продуктов, каждый из которых устанавливал файлы с использованием модулей слияния, и каждый из них можно было бы удалить, не нарушая других из-за подсчета ссылок и того факта, что совместное использование и общий идентификатор компонента делают работу совместного использования по назначению. Поэтому забывайте, что один продукт - это VC-redist, а другой - ваш (или другой, который использует те же файлы) - это всего лишь общий механизм подсчета файлов/ссылок Windows Installer.

Это для последних модулей слияния, которые устанавливают файлы в системную папку. Были также другие схемы, использующие WinSxS и перенаправления политики, которые, похоже, не используются сейчас (VS 2015).