2011-12-13 2 views
3

Это объясняет, но вот оно.Пакет MSI с несколькими экземплярами завершается с ошибкой при обновлении

Мне нужно создать несколько экземпляров MSI, которые устанавливают динамические экземпляры - то есть экземпляры, определенные при установке пакета, а не жестко закодированные в файле MSI. Теперь я уже столкнулся с трудностями создания загрузочного устройства и с помощью MSI api для динамического создания преобразования (MST) и применения его к оригинальной MSI; после долгих переделок, установки и удаления работает нормально (я буду размещать детали по мере необходимости).

В основном, MST содержит преобразования для ProductCode, ProductName, PackageCode (в сводной информации), изменяет идентификаторы GUID для всех компонентов (в противном случае удаление удаляется глупыми способами), а место установки защищено от конфликтов загрузчиком. Кроме того, загрузочный загрузчик запускает установку с параметром командной строки MSINEWINSTANCE = 1, как подробно указано here.

Однако я также хотел бы обновить установленный экземпляр (через основные обновления), что является основной причиной того, почему UpgradeCode уникален (или так я думал). Однако после того, как я увеличиваю версию MSI и пытаюсь запустить ее (снова через загрузчик и передав в ProductCode нужного экземпляра с помощью свойства MSIINSTANCEGUID), он терпит неудачу; в журнале говорится:

=== Verbose logging started: 12/13/2011 17:43:56 Build type: SHIP UNICODE 5.00.7601.00 Calling process: C:\Windows\SysWOW64\msiexec.exe === 
MSI (c) (5C:D0) [17:43:56:120]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg 

MSI (c) (5C:D0) [17:43:56:120]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg 

MSI (c) (5C:34) [17:43:56:120]: Resetting cached policy values 
MSI (c) (5C:34) [17:43:56:120]: Machine policy value 'Debug' is 2 
MSI (c) (5C:34) [17:43:56:120]: ******* RunEngine: 
      ******* Product: D:\TestArea\AMLDC.msi 
      ******* Action: 
      ******* CommandLine: ********** 
MSI (c) (5C:34) [17:43:56:120]: Machine policy value 'DisableUserInstalls' is 0 
MSI (c) (5C:34) [17:43:56:135]: MainEngineThread is returning 1625 
=== Verbose logging stopped: 12/13/2011 17:43:56 === 

и появляется сообщение пользовательского интерфейса, в котором говорится, что «системный администратор установил политики для предотвращения этой установки». Очевидно, что это неверно (политики появятся в журнале, и будет предоставлено более явное сообщение).

Код ошибки 1625, кажется, соответствует "ERROR_INSTALL_PACKAGE_REJECTED".

Любые идеи, что я мог бы попробовать дальше? Я думаю, что MSI-движок должен попытаться сделать в этом случае, изучите UpgradeCode, примените исходное преобразование (которое должно быть кэшировано и доступно через код продукта, который я передаю с помощью параметра MSIINSTANCEGUID). Однако ясно, что двигатель никогда не достигает этого этапа (он должен быть зарегистрирован в файле журнала, верно?)

Вздох, это было гораздо больнее, чем должно было быть.

Edit: спустя некоторое время ...

Краткого примечания об изменении компонентов GUIDs: это только действительно необходимо для компонентов нефайловых (у меня есть некоторые записи реестра, которые я использую для отслеживания экземпляров). Если я не изменю свой идентификатор GUID, они не будут правильно очищены при удалении, как указано here. Для файлов он отлично работает, если пути ключей разные, и я проверял, что, только меняя компоненты реестра в моем коде.

Итак, я узнал, что основные обновления, вероятно, не сработают для меня, если я не изменю код UpgradeCode для каждого экземпляра (поскольку FindRelatedProducts смотрит только на UpgradeCode, я думаю), и я попробовал что-то еще, прежде чем идти там: незначительные обновления.

Запуск установщика для новой версии с/fvamus вместе с MSIINSTANCEGUID = {existing-instance-product-code}, казалось, работал, вплоть до того, как я попытался добавить новый файл в пакет (который я ожидаю произойдет в будущем) ... когда, конечно, это не сработает (компонент для нового файла не установлен при переустановке, конечно).

Так что, вероятно, мне придется либо изменить код UpgradeCode с помощью преобразования, либо посмотреть, что это значит, или повредить свойство вывода FindRelatedProducts через некоторые пользовательские действия и посмотреть, могу ли я убедить основные обновления для работы таким образом.Однако первоначальная проблема (ошибка 1625) была именно с крупными обновлениями, поэтому я не уверен, могу ли я что-то сделать с ней, не зная причину. Чтобы быть совершенно ясным: то, что я вставил выше, является полностью из подробного журнала MSI, он, кажется, не делает ничего перед возвратом с ошибкой 1625. Я также попытался удалить все строки в таблице Upgrade MSI и никаких изменений в поведении не произошло.

Я также не могу тратить гораздо больше времени на эту глупую проблему, поэтому, если ничего другого не будет, я буду вынужден делать тихую деинсталляцию, за которой следует регулярная установка с теми же настройками. Я съеживаюсь от этой мысли, но если это не поможет ...

Редактирование: со всей справедливостью это, вероятно, пошло бы быстрее, если бы я вообще не начинал путь MSI и не закодировал мой собственный установщик из абсолютного царапины, с gzipped потоками и простой xcopy. Даже с задачей msbuild, которая бы сжала файлы из визуальной студии или что-то еще.

+0

У вас возникли трудности с FindRelatedProducts/RemoveExistingProducts или с установкой более новой версии, которая удалит предыдущую часть в рамках основного обновления? Что вы хотите, когда у вас есть 3 экземпляра v1.0 на компьютере, и вы пытаетесь установить v2.0 (основное обновление)? Изменение всех кодов компонентов звучит необычно для меня, но я в основном согласен с тем, что это не похоже на источник текущего симптома. –

+0

При установке новой версии я разрешаю выбор существующего экземпляра через загрузчик; Я бы ожидал, что только этот экземпляр будет обновлен, так как я передаю его MSIINSTANCEGUID. Однако с тех пор я узнал, что FindRelatedProducts смотрит только на UpgradeCode, и до сих пор я сохранял его одинаковым для всех экземпляров. Я пробовал небольшие обновления (через переустановку с/fvamus, который подходит мне просто отлично), и он работает до определенной степени. На самом деле вы знаете, что, я отредактирую вопрос со всей этой новой информацией. –

ответ

0

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

0

Не могли бы вы сделать ваши экземпляры как функции? Затем они будут выбираться во время установки, а обновления будут хорошо работать с ними. Существует даже специальное действие «MigrateFeatureStates» для загрузки состояния уже установленных.

Что касается компонентов, которые отказались очистить - возможно, вам нужно указать persistent = "no" для них явно? Затем их необходимо удалить во время удаления.

+0

Интересная идея, но я чувствую, что создание функций динамически было бы слишком большой работой. Что касается компонентов, которые не очищаются правильно, я имею в виду, что если они имеют один и тот же идентификатор GUID, они считаются разделяемыми, даже если они не являются одинаковыми «объектами» (в случае нефайловых компонентов, таких как записи реестра), так что К сожалению, к сожалению. –

1

Я просто попытался это

msiexec /i <package>.msi /n {<InstanceProductCode>} REINSTALL=ALL REINSTALLMODE=vomus /qb 

Как описано здесь: http://msdn.microsoft.com/en-us/library/aa369528(v=vs.85).aspx

Это делает работу для меня, даже если я добавлять новые файлы в следующей версии MSI.

+0

Интересно; Думаю, я помню, как это пробовал, и это не сработало, но это слишком давно, чтобы быть уверенным; возможно, была и другая особенность моей установки, которая помогла ей справиться. Спасибо за вклад в любом случае, но я не думаю, что у меня будет шанс попробовать его снова скоро ... –

Смежные вопросы