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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

regsvr32 dllname.dll

или

exename.exe / Regserver

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

regsvr32 / u dllname.dll

или

exename.exe / Unregserver

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

Answer 2

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

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

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

Answer 3

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

вопрос "как это работает" потребует очень, очень длинного ответа

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

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

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