WiX: интеграция с парафином и сервером репозитория / сборки
Краткая версия: Как я могу убедиться, что мои GUID компонентов остаются стабильными, используя Paraffin на сервере сборки?
В настоящее время я работаю над проектом, который должен быть развернут через WiX. Поскольку это веб-проект, он содержит много файлов (все еще на ранней стадии и уже почти 200 файлов). Кроме того, в процессе разработки файлы постоянно добавляются и удаляются, поэтому ведение списков компонентов WiX вручную просто невозможно.
Поскольку я много читал о правилах компонентов и о том, что люди, нарушающие их, попадают в ад, я решил пойти с Парафином в качестве сборщика. Этот инструмент способен обновлять существующий список компонентов, не создавая при этом новые GUID для существующих компонентов.
Однако при создании нового компонента инструмент назначает новый GUID. Даже если файлы компонентов идентичны, начальные идентификаторы GUID будут отличаться на разных компьютерах или даже только в разное время.
Поэтому, очевидно, мне нужен центральный орган для исправления начальных идентификаторов GUID. Моя идея заключалась в том, чтобы фиксировать пустые списки компонентов, которые затем заполняются сервером сборки, вызывая Paraffin при сборке. Поэтому, когда я распространяю только MSI, созданные сервером сборки, я могу быть уверен, что соблюдаются правила компонентов.
Однако проблема этого подхода заключается в том, что у меня нет средств для отслеживания моих GUID, в случае сбоя сервера сборки или опустошения его локального репозитория. Я думал о том, чтобы сервер сборки передал сгенерированный список компонентов в мой репозиторий, но это не кажется чистой идеей.
Другое решение, о котором я подумал, заключалось в том, чтобы все разработчики собирали (и, таким образом, вызывали Paraffin) перед фиксацией. Таким образом, каждый разработчик создает начальные идентификаторы GUID для своих вновь добавленных файлов и фиксирует их в списке компонентов.
Очевидная проблема с этим подходом: люди (например, разработчик A) забудут собрать, прежде чем они совершат коммит. Таким образом, в этих случаях сервер сборки будет создавать начальные идентификаторы GUID для новых файлов, но они также будут храниться только локально. Несколько коммитов позже, разработчик B придет и создаст решение, создав новый GUID для файлов, созданных разработчиком A. Затем он зафиксирует список компонентов, содержащий этот GUID, и сервер сборки проверит его. Теперь сервер сборки получил GUID (созданный разработчиком A) для пакета, для которого он ранее использовал другой (самостоятельно созданный) GUID, хотя файлы за это время не изменились.
Итак, как я могу убедиться, что мои GUID остаются стабильными между сборками, не полагаясь на то, что разработчики создадут свое решение до того, как они выполнят коммит? Подходы, изложенные выше, кажутся мне неудовлетворительными, но это все, о чем я могу думать прямо сейчас.
2 ответа
Насколько мне известно, правила для компонентов действительно вступают в действие только тогда, когда у вас есть несколько инсталляторов, которые совместно используют компоненты с одинаковыми руководствами (которые затем должны быть точно такими же ресурсами), или вы используете модуль wixlib или модуль слияния, который затем включены как часть различных установщиков.
Из того, что вы сказали выше, для меня это не звучит так, как вы, поэтому нет никакого вреда в том, чтобы иметь разные руководства по компонентам для каждой сборки. Это будет означать, что при обновлении веб-сайта файлы, которые не были изменены, будут удалены и переустановлены с использованием другого руководства по компонентам. ИМХО, на самом деле это не имеет значения, если установщик правильно устанавливает все файлы, необходимые для работы сайта, и не удаляет компоненты из других продуктов.
Если вы используете элемент MajorUpgrade, старый продукт будет полностью удален до того, как будет установлен новый, поэтому любые руководства по компонентам, которые являются общими для двух версий, будут удалены, а затем переустановлены в любом случае.
Я всегда просто оставляю свои элементы guid как Guid='*' таким образом, я знаю, что никогда не будет каких-либо столкновений гидов ни с одним из моих компонентов в моих нескольких продуктах.
^ Я знаю, что это не теоретически верно, но в данном случае это так.
Не совсем верно. Изменение GUID вашего компонента со сборки на сборку - это хорошо, если и только если вы запланируете RemoveExistingProducts заранее, чтобы файлы не попадали в систему перед переустановкой новых GUID. Этот подход хорошо работает для небольших инсталляторов, у которых не так много файлов, но по мере роста вашего инсталлятора вы почувствуете необходимость вдвое увеличить объем операций ввода-вывода при удалении и переустановке, а не просто перезаписывать файлы. Короче говоря, это зависит от вас, но вы должны тщательно подумать о том, насколько велико ваше приложение, прежде чем перейти к предложенному подходу.