MSI / WiX - Назначение GUID компонента во время преобразования нескольких экземпляров

Используя WiX 3.5, у меня есть MSI с преобразованием экземпляров, что позволяет мне устанавливать программное обеспечение на одном компьютере с разными названиями продуктов. Для этого у меня есть «жестко запрограммированный» список идентификаторов и имен продуктов в файле .wxs, определенных условно. Однако у меня есть только одно определение Feature-ComponentRef, которое включает как файловые, так и нефайловые ресурсы.

Установка, похоже, проходит нормально, но удаление экземпляров демонстрирует поведение, упомянутое в этих двух источниках:

http://msdn.microsoft.com/en-us/library/aa367797(v=VS.85).aspx

и

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Proposed-Simple-Addition-to-WiX-to-Make-Them-Easier-td708828.html

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

Я предполагаю, что это связано с отсутствием уникального GUID для нефайловых компонентов (тогда как это не проблема для файловых компонентов)

Итак, мне было интересно, будет ли действительным подходом определить один файл .wxs с одним идентификатором продукта, именем и одним набором функций, но иметь настраиваемый загрузчик, генерирующий новые GUID для продукта и нефайловых компонентов, которые затем вставляются в базу данных MSI во время выполнения? то есть, когда приходит время удалить или обновить, я бы запросил реестр для установленных экземпляров и затем получил их GUID.

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

Имеет ли это смысл? Сделает ли Burn все лучше? :)


person ayang    schedule 18.02.2011    source источник


Ответы (2)


Начиная с версии v3.6.1511.0, для компонентов добавлен атрибут «MultiInstance». Это позволяет на лету создавать руководство для каждого экземпляра в соответствии с предложением Джоша Роуза в его сообщении в список рассылки WiX (см. Ссылку в OP). Я проверил, и это работает правильно, чтобы данные реестра удалялись при удалении текущего экземпляра, а не при удалении ПОСЛЕДНЕГО экземпляра.

person Eric H    schedule 02.06.2011
comment
Вау! Не могу дождаться, чтобы попробовать это! Спасибо! - person ayang; 03.06.2011

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

Создание нескольких экземпляров с помощью преобразований экземпляров

В статье упоминается:

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

Я вообще-то не знаю, о чем они там говорят. Я создал многоуровневые установщики с несколькими экземплярами, в которых все файлы были изолированы уникальным INSTALLDIR (настраиваемое действие типа 51 во время выполнения для изменения места назначения на основе InstanceID), и все данные реестра были изменены с использованием InstanceID как части пути, как упоминалось в статье. Я поддерживал до шестнадцати уникальных экземпляров с уникальными данными конфигурации и уникальными номерами версий (каждый экземпляр можно было обслуживать путем серьезного обновления, кроме других экземпляров). Все это было сделано для поддержки модели развертывания SaaS для приложения nTier, и я никогда не когда-либо приходилось создавать компоненты с уникальными GUIDS и / или условными выражениями.

Единственное, что мне пришлось сделать, так это то, что на стороне клиента они хотели ярлык на рабочем столе. (Клиент поддерживал несколько экземпляров также потому, что на сайте может быть версия 1.0 в рабочей среде и версия 1.1 в тестовой)

Поскольку я не мог изменить имя папки (исправлено) и поскольку таблица MSI ShortCut не поддерживает форматируемую таблицу, мне пришлось написать настраиваемое действие для динамического создания ShortCut при установке таблицы с использованием InstanceID в таблицу TEMP, а затем MSI создал ярлык для меня.

person Christopher Painter    schedule 18.02.2011
comment
Привет, Кристофер - спасибо за ответ. Вы правы в том, что я могу изменить данные реестра, но проблема возникает при удалении. Фактически удаляются только данные реестра для последнего удаленного экземпляра - при всех предыдущих удалениях данные реестра не удаляются. Именно здесь, как я понимаю, появляются уникальные идентификаторы GUID компонентов. Сообщение Джоша Роу в списке рассылки wix-users (ссылка в OP) описывает это - это примерно 2 / 3–3 / 4 пути вниз по его сообщению. - person ayang; 22.02.2011
comment
Придется поиграться с этим. Я не выполнял установку нескольких экземпляров с 2006/2007 года и просто не помню, чтобы это было проблемой. Я почти уверен, что в этих установках были какие-то данные реестра, но, может быть, нет, возможно, я был полностью XML. - person Christopher Painter; 22.02.2011
comment
На самом деле, я знаю, что у меня были данные реестра. Я использовал его для сохранения данных INSTALLDIR, чтобы при крупном обновлении новый MSI / экземпляр мог определить местоположение, для которого была настроена исходная установка / экземпляр. Я собираюсь смоделировать это, чтобы освежить свою память. - person Christopher Painter; 22.02.2011
comment
Хорошо, я поправился. Когда я сказал, что не знаю, о чем они говорят, должно быть, я не знаю, о чем говорю! :-) Я только что скопировал установщик и вижу то же поведение, что и вы. - person Christopher Painter; 22.02.2011
comment
Как выглядит ваше настраиваемое действие для ярлыков? - person Horcrux7; 26.01.2016