Ускорьте процесс сборки WiX-Installer

Для своего проекта Wix я собираю 4 каталога с помощью события предварительной сборки Visual Studio, в результате чего получается около 160 МБ данных и около 220 файлов, но процесс сборки занимает очень много времени.

Как я могу ускорить этот процесс? У меня есть один встроенный файл media.cab, в котором будут храниться все файлы. Это размер или количество файлов, которые замедляют процесс? Или это сбор урожая с помощью теплового инструмента в мероприятии перед сборкой? Было бы быстрее с элементом HeatDirectory?

У кого-нибудь есть опыт ускорения этого?


person Postback    schedule 04.05.2015    source источник


Ответы (3)


Файл справки WiX: Как: оптимизировать скорость сборки. Другими словами: 1) Cabinet reuse и 2) multi-threaded cab creation - встроенные механизмы в WiX для ускорения сборки.


Оборудование: неизбежное "throw hardware at it". Новые диски SSD и NVMe настолько быстрее, чем старые диски IDE, что вы можете попробовать их как еще один способ повысить скорость сборки и скорость установки. Очевидно, да, но очень важно. Это действительно может улучшить скорость разработки. См. этот ответ.

Проблемы с накопителями NVMe?: 1) Они перегреваются, 2) обычно имеют ограниченную емкость (размер), < strong> 3) они могут быть более уязвимыми, чем старые диски 2.5 при использовании в ноутбуках (я не уверен - имейте в виду, что некоторые диски NVMe припаяны к материнской плате на ноутбуках), _11 _ Спасение данных может быть немного сложным, если у вас нет качественных внешних корпусов (форм-фактор и т. д.), 5) диски NVMe со временем сгорают, 6) < / strong> Они по-прежнему довольно дорогие, особенно диски большей емкости, и наверняка есть и другие проблемы - но в целом: эти диски прекрасны.


Сжатие: вы можете попробовать скомпилировать свою настройку с другим уровень сжатия (например, none для отладочных сборок). Отсутствие сжатия ускоряет сборку. Вот иллюстрации, как сделать обратное, установив более высокое сжатие (просто не используйте для ваших целей none вместо high):

Связанный ответ о сжатии: Что такое сжатие метод, используемый файлами MSI?

Раздельная установка. Если вы по-прежнему используете сжатие, вы можете поместить необходимые компоненты и модули слияния в отдельные setup, чтобы не сжимать их для каждой сборки (или используйте флаги выпуска, если вы находитесь в Installshield, или проверьте Препроцессор в Wix).

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

Shim. Другой способ - это совместить все устанавливаемые файлы с размером 1 КБ, если то, что вы тестируете, сама установка, ее графический интерфейс и пользовательские действия. В таком случае это просто оболочка настройки - отличный способ протестировать новые настраиваемые действия в вашей настройке. Многие написали инструменты для этого, но у меня нет для вас ссылки. Всегда есть github.com для поиска.

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


Отладочная сборка: я обычно использую комбинации этих методов для создания отладочной сборки.

  • Обычно я использую внешние исходные файлы, когда экспериментирую и добавляю новые функции, а также постоянно перестраиваю и устанавливаю установку.
  • Флаги выпуска для компиляции только части установки, повторное использование кабинета и флаги выпуска вместе могут сэкономить много времени в зависимости от размера вашей установки, количества файлов и конфигурации вашего оборудования.
  • Возможно, наиболее эффективным, на мой взгляд, является отдельная настройка (при условии, что она стабильна и не меняется так часто). Однако будьте осторожны: Wix для установки нескольких приложений (проблемы, возникающие, когда он доходит до расщепления сетапов).

Мое мнение: выберите отдельную настройку только для предварительных условий. Это также хорошо для сценариев крупномасштабного развертывания, когда корпоративные пользователи хотят использовать свои собственные стандартизованные предварительные условия и их раздражает большое количество встроенного мусора в огромной конфигурации. В крупных компаниях много времени на подготовку пакетов уходит на устранение устаревших сред выполнения и предварительных требований. Вы также можете доставлять обновления для этих предварительных условий, не перестраивая всю настройку. Хорошая развязка.


Ссылки:

person Stein Åsmul    schedule 04.05.2015
comment
на самом деле уровень сжатия в значительной степени сэкономил мне половину времени сборки, но теперь у меня около 450 МБ вместо 160 МБ. Что вы имеете в виду под внешним исходным файлом? - person Postback; 05.05.2015
comment
Любопытно, а для уровня сжатия вы ничего не установили? Как низкая производительность? - person Stein Åsmul; 05.05.2015
comment
Да, я установил значение none, а затем я получил файл 450 МБ, но также примерно половину времени сборки - person Postback; 05.05.2015

Для нас подавляющее большинство времени было потрачено на вызов light (для фазы компоновки).

light очень медленно сжимает шкафы. Очень помогает изменение DefaultCompressionLevel в .wixproj с high на mszip (или low или none). Однако наша сборка все еще шла слишком медленно.

Оказывается, light обрабатывает шкафы независимо и по умолчанию автоматически связывает их в нескольких потоках. Чтобы воспользоваться этим параллелизмом, вам нужно создать несколько шкафов. В нашем элементе .wxs Product у нас было следующее, которое поместило все в один шкаф:

<MediaTemplate EmbedCab="yes" />

Оказывается, вы можете использовать атрибут MaximumUncompressedMediaSize, чтобы объявить порог (в МБ), при котором вы хотите, чтобы файлы автоматически сегментировались в разные файлы .cab:

<MediaTemplate EmbedCab="yes" MaximumUncompressedMediaSize="2" />

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

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

<CabinetCachePath>$(OutputPath)cabcache\</CabinetCachePath>
<ReuseCabinetCache>True</ReuseCabinetCache>

Подавление проверки также дает хорошее ускорение (по умолчанию light.exe тратит около трети своего времени на проверку .msi). Мы активируем это для отладочных сборок:

<SuppressValidation>True</SuppressValidation>

С этими изменениями наша окончательная (инкрементная) сборка увеличилась с более чем минуты до нескольких секунд для вывода .msi размером 32 МБ, а полная перестройка оставалась менее чем за минуту, даже с уровнем сжатия high.

person Cameron    schedule 28.11.2019

Проще говоря, не собирайте файлы. См. Статью в моем блоге: Работа с очень большое количество файлов

Третий недостаток заключается в том, что ваша сборка займет НАМНОГО больше времени, поскольку она не только создает ваш пакет, но также создает и проверяет определения ваших компонентов.

Я поддерживаю проект с открытым исходным кодом на CodePlex под названием IsWiX. Он содержит шаблоны проектов (строительные леса) и графических дизайнеров, которые помогут вам в настройке и поддержке вашего источника WiX. Тем не менее, он был разработан вокруг модулей слияния, что немного замедляет сборку, поскольку .MSM должен быть собран, а затем объединен с .MSI. Чистые фрагменты будут быстрее, если вас действительно беспокоит чистая скорость. Тем не менее, у меня много установщиков размером около 160 МБ, и это совсем не занимает много времени.

И, конечно, не забывайте о машине для быстрой сборки. ЦП, ОЗУ и ввод-вывод SSD-диска - все это способствует быстрой генерации MSI. Для консультаций я использую Microsoft Visual Studio Online (VSO). У меня есть сервер Core i7-2600k Hyper-V с 32 ГБ оперативной памяти и SSD Samsung 850evo. На моем сервере сборки (ВМ) работает прокси-сервер TFS для локального кэширования SCC.

Ради интереса, на указанном выше компьютере я взял 220 файлов из папки system32 общим размером 160 МБ. На создание MSM потребовалось 30 секунд, а на создание MSI - всего 60 секунд. Для меня это «достаточно быстро». Я ожидал, что MSI, созданный с использованием только фрагментов, займет 30 секунд.

person Christopher Painter    schedule 04.05.2015
comment
Я действительно измерил скорость сейчас. С тепловым инструментом я получил 102 секунды, с отключенным нагревом и только что взял сгенерированные файлы, это было около 101 секунды, поэтому создание файлов не проблема. Так это переменные препроцессора или действительно количество данных? Мой компьютер не такой медленный, и я использую I7-3770 с тактовой частотой 3,4 ГГц. - person Postback; 04.05.2015
comment
Сканер вирусов? Вам нужно будет поделиться со мной своим контентом, чтобы я посмотрел глубже. Тепло может быть не медленнее в вашей ситуации, но я видел это. Особенно, когда вы начинаете вовлекать сбор COM. - person Christopher Painter; 04.05.2015