Cómo funciona el registro COM en Windows

Question

Soy un desarrollador de aplicaciones que intenta dar sentido a cómo las claves de registro COM (SelfReg) se relacionan con el .dll dado en Windows.

ProgID's, AppID's, TypeLibs, Extensions & Los verbos están todos relacionados con el CLSID ¿verdad? ¿Los CLSID siempre usan ID de Prog/App o podría simplemente tener una clase de extensión de archivo? ¿Qué bits son opcionales?

Parte de esto parece ser "como un enrutador" donde están las dos interfaces (interna - .dll) y externa (la extensión, etc.).

¿Cómo encaja todo esto? (La documentación del SDK no tiene sentido para mí)

Pregunto porque todo esto es fundamental para la 'cicatrización' de aplicaciones con Windows Installer (que los empaquetadores son 'grandes', pero no hay fallas esenciales ya que una cosa codificadora realmente)

--- Edit: ¿Estoy seguro al asumir que para lo que COM está registrado, todo debe vincular al CLSID y no puede ser un 'callejón sin salida'? Los verbos necesitan extensiones que necesitan progid ...

¿Qué pasa con las AppId, TypeLibs e Interfaces? ¿Cómo se interrelacionan?

Answer 1

Lo primero que se debe tener en cuenta, es que COM dlls se registren. Pondrán todas las entradas requeridas en los lugares correctos en el registro.

Creo que la respuesta a su pregunta central sobre qué bits son opcionales es, probablemente, que todos son opcionales para diferentes tipos de objetos. Los objetos de automatización requieren Prog/AppID si se pueden crear públicamente, pero pueden no hacerlo si solo se crean internamente, de forma similar una clase COM que no se puede crear públicamente se puede enumerar.

Muchos objetos COM que no tienen interfaces de automatización (como muchas de las clases COM utiliza Microsoft internamente en las ventanas no tendrá ningún ProgId sino que simplemente tiene una entrada en su CLSID en HKCR \ CLSID.

Si yo entiendo que correctamente le interesa esto desde el punto de vista del instalador. me imagino que todo lo que necesita hacer es preguntar al usuario especificar qué archivos DLL se selfregistering y luego llamar

regsvr32 dllname.dll

o

EXENAME.EXE/Regserver

para un servidor fuera de proceso. Si algo sale mal solo necesitas llamar a los opuestos.

regsvr32/u dllname.dll

o

EXENAME.EXE/Unregserver

espero que esto responda a su pregunta.

Answer 2

Recomendaría el libro Inside COM.

No era la referencia más actualizada, incluso durante el apogeo de COM, pero explica bastante bien los conceptos básicos, incluyendo todos los datos de registro. Además, apuesto a que puedes obtener una copia usada realmente barata.

Sé que esto no es una respuesta, pero recordando lo que el capítulo sobre el registro parecía - un no-específica "cómo funciona" cuestión requerirá un muy, muy respuesta larga ...

Answer 3

Utilicé una respuesta porque los comentarios parecen muy limitados. No sabe cómo va a interpretar este SO (? Tal vez voy a se considerará loco por hablar solo)

"cómo funciona" cuestión requerirá una respuesta muy, muy larga

Gracias - Lo que intento lograr es una comprensión de eso sin ser realmente un desarrollador: esto se debe a la forma en que los empaquetadores intentan agrupar las claves de registro COM con el .dll (en el mismo componente) para que la resiliencia de la aplicación funcione.

Esto significa 'atrapar' la COM desde el registro de los archivos .dll y asociarlo en las tablas de publicidad correctas (CLSID, AppID ... hasta la saciedad) al componente que tiene el .dll. A veces esto no es fácil de ver y, a veces (me dicen) puede romper la aplicación del funcionamiento. Me dijeron que el COM no necesita para ser completo (autorreferencial).

Todavía estoy tratando de entender esto. Por supuesto, si el empaquetador captura toda la información pero no asocia la información COM al .dll, los regkeys aún se escriben en el momento de la instalación, simplemente el MSI no cuida a la aplicación si las cosas van mal (que casi nunca)