Общая концепция MSI заключается в том, что существует 1: 1 отображение между
GUID компонента (уникальный идентификатор) и абсолютный путь
(установить местоположение / путь к ключу). Полный путь, включая имя файла, если
любой. Смотрите обновление ниже для новой функции Wix, чтобы иметь дело автоматически
с этим.
Я использую некоторые простые правила для работы с слишком сложными и бессмысленными правилами для компонентов:
- Всегда используйте отдельный компонент для файла (даже для не двоичных файлов). Это позволяет избежать всевозможных проблем. Есть несколько исключений:
- Многофайловые сборки .NET все должны быть в одном компоненте, поскольку они всегда должны устанавливаться / удаляться как единое целое.
- Несколько других общих типов файлов входят в "совпадающие пары" - они принадлежат друг другу. Часто это файлы содержимого и индекса. В качестве примера рассмотрим файлы справки Microsoft:
- .HLP и .CNT файлы принадлежат друг другу.
- .CHM и .CHI файлы принадлежат друг другу.
- Вероятно, существует несколько таких типов файлов, которые принадлежат друг другу и, следовательно, должны быть помещены в один и тот же компонент, поэтому они устанавливаются / удаляются вместе - я подозреваю, что определенные файлы сертификатов являются кандидатами. Трудно придумать определенный список. Просто спросите себя «всегда ли эти файлы принадлежат друг другу» - поэтому они всегда отображаются парами, когда появляется новая версия? Если да, то установите их через один и тот же компонент. Установите версионный файл, если он есть, в качестве ключевого файла.
- Я хочу добавить файлы драйверов в качестве примера группы файлов, всегда принадлежащих друг другу:
SampleDriver.cat
, SampleDriver.inf
, SampleDriver.sys
, SampleDriver.cer
. Все они должны совпадать как «юнит» для развертывания.
- Помните, что после того, как вы присвоили GUID для компонента, он становится неизменным для ключевого пути этого компонента (абсолютный путь). Если вы перемещаете файл в новое место или переименовываете файл, присвойте ему новый GUID компонента (поскольку абсолютный путь отличается, это фактически новый идентификатор).
- В итоге идентификаторы GUID компонента привязаны к абсолютному месту установки, а не к конкретному файлу. GUID не следует за файлом, если он перемещается . Ссылка GUID учитывает абсолютное местоположение, а не файл как таковой.
- Не добавлять и не удалять файлы из существующего компонента. Все виды проблем обновления и исправлений. Вот почему, как правило, мне нравится один файл на компонент.
- Существует намного больше ссылок на компоненты, но я оставлю это для "обзора".
Некоторые образцы:
- Вы переименовываете файл C: \ Program Files \ MyCompany \ MyApp \ MyFile.exe в C: \ Program Files \ MyCompany \ MyApp \ MyFile_NEW.exe . Что это значит для создания компонентов? Это новый абсолютный путь установки, поэтому вы генерируете новый GUID для хост-компонента, ИЛИ добавляете новый компонент и удаляете старый (что имеет тот же эффект).
- Ваш обновленный MSI предоставляет новую версию MyFile.exe. Расположение такое же, как и раньше, это означает, что GUID компонента не должен изменяться. Это тот же файл (личность), только в другой версии.
ОБНОВЛЕНИЕ : WIX теперь имеет новую функцию автоматического генерирования GUID компонента , которая вычисляет GUID пока целевой путь остается прежним. Я не пробовал это, если честно, но многие, кажется, используют его без проблем, и Роб Меншинг (автор Wix) утверждает, что это безопасно для нормального использования . В качестве концепции я настоятельно рекомендую это, поскольку он включает в себя auto-magic и защищает вас от некоторой сложности.
Также обратите внимание, что вы можете не указывать много исходных атрибутов из вашего xml-файла Wix и полагаться на значения по умолчанию Wix вместо значений жесткого кодирования.