Какова лучшая практика генерации компонентов MSI?

Question

Установщик Visual Studio утверждает, что рекомендуется устанавливать каждый файл в качестве компонента установщика. Тепловая утилита, поставляемая с Wix, также, похоже, следует практике помещения каждого файла в отдельный компонент.

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

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

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

Преимущество практики 2 можно увидеть в установке, которая устанавливает сотни графических файлов в один каталог. Если вам не нужны функции восстановления, есть ли причина создавать сотни компонентов для этой установки?

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

Answer 1

Я всегда использую подход Microsoft (что-то похожее на то, что делает InstallShield): http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx

Я думаю, что это лучше, потому что: - важные файлы (EXE, DLL и т. Д.) Имеют свой собственный компонент, поэтомуих можно легко исправить - файлы ресурсов сгруппированы вместе - это позволяет оптимально рассчитывать количество компонентов (не слишком много для длительной установки, но достаточно для легкого восстановления)

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

Answer 2

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

Я работаю над установками с более чем 15 000 файлами, и мы обслуживаем только крупные обновления. Для «исполняемых программ» мы следуем принципам 1: 1 (обязательно для COM, Services, ShortCuts и т. Д. В любом случае), но для файлов контента / данных мы на самом деле делаем один ко многим без подхода с использованием ключевого файла, чтобы сократить наше компоненты. Конечно, это означает, что мы не сможем создать MSP, который обслуживает только один или два файла содержимого здесь и там, но для нужд нашего бизнеса это просто не важно для нас.

Resilency было для нас чем-то вроде четырехбуквенного слова, так что меньшее количество ключевых файлов делает нас счастливее в любом случае. :-) Кстати, VDPROJ также делает каждый ключ реестра ключевым файлом своего собственного компонента, и это было довольно болезненно для нас, вызывая ненужные исправления.

Все это в стороне, для тех, кто не до конца понимает все это, я буду придерживаться схемы 1: 1, пока вы не столкнетесь с ситуацией, когда вы больше не хотите, и не поймете влияние делая этот выбор.