Таблица классов сгенерировала проблему значения InprocServer32 - PullRequest
Новая
       19

Таблица классов сгенерировала проблему значения InprocServer32

1 голос
/ 01 сентября 2010

Я устанавливаю элемент управления Active X, который содержит некоторые COM-серверы. Я использую опцию COM ExtractShield InstallShield для создания информации реестра. Это приводит к большому количеству записей в таблицах Registry и Class. (Извлеченная информация во многом похожа на Wix).

Похоже, что мой COM-сервер установлен правильно, за исключением дополнительного значения InprocServer32 в ключе InprocServer32, которое выглядит следующим образом: 

HKCR\CLSID\{MY-COM-GUID}\InprocServer32
    (Default) = C:\Path-to-my\file.ocx
    InprocServer32 = 8tYCAGak)9S9&~swl.$?MyFeatureName>*&N$B'fk?As1x2J653?'

Единственное, что я могу понять из дополнительного значения, это MyFeatureName, которое является внутренним именем функции MSI, содержащей файл .ocx. Ключ не указан в таблице реестра, поэтому он должен генерироваться таблицей классов.

Проблема, с которой я сталкиваюсь, возникает только в Windows Server 2008. Кажется, что приложение, пытающееся использовать COM-сервер, не может найти путь к файлу .ocx из значения (по умолчанию), а вместо этого находит Значение InprocServer32. Это приводит к тому, что приложение запускает MSI, а затем MSI застревает в чем-то вроде бесконечного цикла.

Мне интересно, является ли это известной проблемой в Windows Server 2008 или существует ли способ предотвратить создание этого дополнительного значения msiexec.

Ответы [ 2 ]

1 голос
/ 01 сентября 2010

Я не могу помочь вам диагностировать, что происходит, я просто немного пробормотал о том, что все это значит.Это контрмера против DLL Ада.Предполагается, что оно защищает ваше приложение от какой-либо другой программы установки, которая может перезаписать ключи реестра вашего COM-сервера.В частности, ключ (по умолчанию), который задает местоположение для DLL вашего сервера.

По поддельному значению InprocServer32 приложение может автоматически определить, что ключ по умолчанию был перезаписан, и автоматически запустить MSI для устранения повреждения.Это то, что вы видите.

Мне очень не нравится эта функция, это всего лишь еще одна точка отказа в том, что уже трудно устранить, когда он взорвется.И это бесполезная функция, предполагающая, что другой установщик не использует точно такую ​​же контрмеру.Который работал бы 10 лет назад.

Не знаю, что бы вы сделали, чтобы устранить эту конкретную ошибку.А потом просто нажми на эту кр * п и пусть серверы просто сами себе.По крайней мере, у вас будет с чем работать, когда , что не работает.

0 голосов
/ 01 сентября 2010

Я бы прочитал эту статью и посмотреть, поможет ли она вам достичь того, чего вы хотите:

Рекомендация RobMen: не рекламировать информацию COM в MSI

Возможно, вы захотите отключить извлечение COM InstallShield при сборке и вместо этого выполнить однократное извлечение COM для рассматриваемого компонента. Затем вы можете перейти в раздел «Дополнительно к компонентам» и вручную манипулировать информацией в реестре / таблице таблиц так, как вы хотите.

Если вы вообще используете WiX, другой рабочий процесс / хитрость заключается в использовании Heat для построения MSI или MSM вокруг вашего COM-сервера. Затем используйте InstallShield для редактирования MSI / MSM в прямом режиме и просмотра реестра, чтобы экспортировать ключи / значения реестра в файл .REG. Затем импортируйте этот файл .REG в ваш компонент в вашем реальном проекте установки.

...