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