Как работает регистрация COM в Windows

Question

Я являюсь прикладным упаковщиком, пытающимся понять, как ключи реестра COM (SelfReg) взаимосвязаны с данным .dll в Windows.

ProgID's, AppID, TypeLibs, расширения & Глаголы все связаны вокруг CLSID правильно? У CLSID всегда используются идентификаторы Prog/App или вы можете просто иметь класс расширения файлов? Какие биты являются необязательными?

Некоторые из них, похоже, «как маршрутизатор», где есть два интерфейса (внутренний - .dll) и внешний (расширение и т. Д.).

Как все это подходит? (Документация SDK для меня не имеет смысла)

Я спрашиваю, так как все это имеет ключевое значение для приложения «исцеление» с помощью установщика Windows (все упаковщики все «большие», но нет никаких ничтожных сбоев, поскольку его кодер-вещь действительно)

--- Редактировать: Я уверен, что для того, что зарегистрирован COM, он должен все ссылаться на CLSID и не может быть «тупиком»? Глаголы нуждаются в расширениях, которые нуждаются в progid ...

Как насчет AppId's, TypeLibs и интерфейсов? Как они взаимосвязаны?

Answer 1

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

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

Многие объекты COM, которые не имеют интерфейсы автоматизации (например, многие из COM-классов Microsoft использует для внутренних в окнах не будет иметь никакого ProgId, а просто иметь запись под их CLSID в HKCR \ CLSID.

Если Я вас правильно понял вы заинтересованы в этом с точки зрения установки. Я предположил бы, что все, что вам нужно сделать, это попросить пользователя указать, какие библиотеки являются selfregistering, а затем вызвать

regsvr32 dllname.dll

или

exename.exe/RegServer

для отказа от сервера процесса. Если что-то пойдет не так, вам просто нужно вызвать противоположности.

regsvr32/U dllname.dll

или

exename.exe/Unregserver

Я надеюсь, что это ответ на ваш вопрос.

Answer 2

Я бы рекомендовал книгу Inside COM.

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

Я знаю, что это не ответ, но вспомнив, что глава о реестре выглядела - неспецифический «как это работает» вопрос потребует действительно, действительно длинного ответа ...

Answer 3

Я использовал ответ, потому что комментарии кажутся настолько ограниченными. Не знаете, как SO будет интерпретировать это (? Может быть, я буду считать сумасшедшим для разговаривать с самим собой)

«как это работает» вопрос потребует очень, очень длинный ответ

спасибо - то, что я пытаюсь добиться, - это понимание этого, фактически не являясь разработчиком - это из-за того, что пакеты пытаются сгруппировать ключи реестра COM с .dll (в том же компоненте), чтобы работать с отказом приложений.

Это означает «захват» COM из регистрации .dll и связывание его в правильных рекламных таблицах (CLSID, AppID ... ad nauseum) компоненту, который содержит .dll. Иногда это непросто видеть, и иногда (я говорю) это может нарушить работу приложения. Мне сказали, что COM не нужно быть полным (самореферентным).

Я все еще пытаюсь обогнуть все это. Конечно, если упаковщик захватывает всю информацию, но не связывает COM-информацию с .dll, ключи regques все еще записываются во время установки, просто MSI не подходит для приложения, если что-то пойдет не так (который почти никогда не был)