Программа удаления MSI не выполняет класс установщика с тегом [RunInstaller] - PullRequest
Новая
       11

Программа удаления MSI не выполняет класс установщика с тегом [RunInstaller]

0 голосов
/ 14 декабря 2009

Мы разрабатываем решение для установки MSI (к сожалению, на основе VDPROJ), которое установит экземпляр нашего серверного приложения. Программа установки была разработана для поддержки концепции установки нескольких экземпляров. Это означает, что мы написали небольшую утилиту, которая берет MSI-заглушку, а затем выводит сконфигурированный MSI с уникальным кодом продукта, названием продукта и т. Д. Среди прочего. Код продукта обновляется как в таблице свойств, так и в потоке сводной информации.

На этапе установки все работает нормально. Наши два тестовых экземпляра, AcmeCorp и ZurgCorp, установлены бок о бок просто отлично. Все их службы Windows зарегистрированы и работают должным образом.

Однако мы столкнулись с очень странной проблемой при удалении одного из этих экземпляров. Не имеет значения, какой экземпляр мы удаляем первым. Но какой бы из них мы ни выбрали, деинсталляция будет продолжаться очень быстро, но настолько быстро, что фактически пропускается вызов нашего подкласса .NET Installer (с тегом RunInstaller и вызовом CustomAction).

Удаление будет «успешным», а MSI будет удален из списка «Установка и удаление программ». Но служба Windows остается позади, потому что программа удаления MSI никогда не запускает нашу сборку, чтобы удалить ее!

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

Так что же здесь происходит?

Мне пахнет какой-то формой подсчета ссылок. Но где? Мы следовали этой книге, чтобы удостовериться, что Код продукта отличается. Может быть, мы что-то упустили из-за Идентификатора компонента?

Спасибо.

1 Ответ

1 голос
/ 14 декабря 2009

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

В любом случае, обходной путь такой: -

Используйте Orca, чтобы посмотреть на ваш MSI. Зайдите в стол под названием Component. В этой таблице есть столбец с именем ComponentId. Значения для всех них должны быть обновлены, чтобы иметь новое значение (новый GUID). Ни один из других столбцов не имеет значения, столбец Component, имеющий префикс C__, используется только внутри базы данных MSI. Как объяснено, критическим является ComponentId, потому что именно он хранится (хотя и в некоторой хешированной / зашифрованной форме) в реестре Windows и используется MSI для хранения счетчиков ссылок.

Подробнее об этом столбце ComponentId здесь: http://msdn.microsoft.com/en-us/library/aa368007(VS.85).aspx

Чтобы автоматизировать это, я собираюсь улучшить нашу утилиту "Instance MSI Generator", чтобы в основном генерировать новый GUID для каждой записи в таблице Component.

...