Внезапно обнаружил чудную проблему с деинсталяцией COM-объектов.

Есть два MSI-пакета с COM-объектами: для 32 и 64 бит.

Оба ставятся и работают как ожидается.

При деинсталляции одного из них, перестает работать второй.

Исследование показало, что оба пакета создают ProgID-ы в HKCR.

И когда деинсталлируется любой из пакетов, он эти ProgID-ы удаляет.

Поэтому второй пакет перестает работать.

Если руками добавить удаленный ProgID (или выполнить repair второго пакета), то второй пакет снова начинает работать.

Я свято верил, что MSI (где-то) хранит счетчики использования ключей реестра и не удаляет их если счетчик не обнулен.

Нашел в сети вот этот древний топик, но решения не увидел

Как эта проблема решается?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Как эта проблема решается?
А разве в винде нет двух разных веток в реестре для 32x и 64x битных COM объектов?

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Как эта проблема решается?
_>А разве в винде нет двух разных веток в реестре для 32x и 64x битных COM объектов?

Есть, но некоторые вещи общие. В том числе ProgID и сведения об интерфейсах.

Я решил обозначенную проблему разделением регистрации COM объекта на две компоненты.

У первой уникальный GUID для win32/win64 и она содержит данные для регистрации в HKCR\CLSID, в HKCR\Interface и в HKCR\TypeLib

Вторая имеет стабильный GUID и содержит данные для регистрации ProgID

---
Конечно было бы неплохо иметь эту поддержку со стороны WIX, но увы.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, kov_serg, Вы писали:

_>>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>>Как эта проблема решается?
_>>А разве в винде нет двух разных веток в реестре для 32x и 64x битных COM объектов?

КД>Есть, но некоторые вещи общие. В том числе ProgID и сведения об интерфейсах.

КД>Я решил обозначенную проблему разделением регистрации COM объекта на две компоненты.

КД>У первой уникальный GUID для win32/win64 и она содержит данные для регистрации в HKCR\CLSID, в HKCR\Interface и в HKCR\TypeLib

КД>Вторая имеет стабильный GUID и содержит данные для регистрации ProgID

КД>---
КД>Конечно было бы неплохо иметь эту поддержку со стороны WIX, но увы.
А merge module не спасет в данном случае? Т.е. перенести общие части (ключи реестра) туда и использовать в обоих инсталяторах. не знаю, как это работает в случае x86 и x64, но был опыт использования в разных MSI одной битности, все было ок

Здравствуйте, Lonely Dog, Вы писали:

КД>>Я решил обозначенную проблему разделением регистрации COM объекта на две компоненты.

КД>>У первой уникальный GUID для win32/win64 и она содержит данные для регистрации в HKCR\CLSID, в HKCR\Interface и в HKCR\TypeLib

КД>>Вторая имеет стабильный GUID и содержит данные для регистрации ProgID

КД>>---
КД>>Конечно было бы неплохо иметь эту поддержку со стороны WIX, но увы.
LD>А merge module не спасет в данном случае? Т.е. перенести общие части (ключи реестра) туда и использовать в обоих инсталяторах. не знаю, как это работает в случае x86 и x64, но был опыт использования в разных MSI одной битности, все было ок

Я так полагаю, в msm надо выносить целиком компоненту — файлы и правила их регистрации.

Выносить ключи регистрации — смысла нет.

Проблему нужно воспринимать как косяк со стороны WiX.

Они просто не прорюхали этот момент и не реализовали поддержку.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Проблему нужно воспринимать как косяк со стороны WiX.
КД>Они просто не прорюхали этот момент и не реализовали поддержку.

Да они последние несколько лет как-то вообще вяло разрабатывают опен-сорс версию IMHO.
После того как этот firegigant сделали, новые вещи все в проприетарщину утащили, а саппорт по сотне в час продавать начали.
"Харвестинг" (про что ты говоришь) тоже там. Бабло победило.