windows - reiniciar - tag editor music pc
Cómo funciona el registro COM en Windows (3)
Lo primero que debe darse cuenta es que los dlls COM se registran. 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 que microsoft usa internamente en Windows no tendrán ningún ProgId, sino que simplemente tendrán una entrada en su CLSID en HKCR / CLSID.
Si te entiendo correctamente, estás interesado en esto desde la perspectiva del instalador. Me imagino que todo lo que necesita hacer es pedirle al usuario que especifique qué dlls se autoregistran 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 tu pregunta.
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, AppID, TypeLibs, Extensions & Verbs están todos vinculados al 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?
Algo 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í)
Lo pregunto, ya que todo es fundamental para la "cicatrización" de aplicaciones con Windows Installer (que los empaquetadores son "grandes", pero no hay fallas esenciales ya que es una cosa codificadora)
--- Editar: ¿Estoy seguro al asumir que por 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é hay de las AppId, TypeLibs e Interfaces? ¿Cómo se interrelacionan?
Yo recomendaría el libro Inside COM .
No fue la referencia más actualizada, incluso durante el apogeo de COM, pero explica bastante bien los conceptos básicos, incluido todo el contenido esencial del registro . Además, apuesto a que puedes obtener una copia usada realmente barata.
Sé que esto no es una respuesta, pero al recordar cómo era el capítulo sobre el registro, una pregunta no específica de "cómo funciona" requerirá una respuesta realmente larga ...
Utilicé una respuesta porque los comentarios parecen muy limitados. No estoy seguro de cómo lo interpretará SO (¿se me considerará loco por hablar solo?)
La pregunta "¿cómo funciona?" requerirá una respuesta realmente 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'' el COM del registro del .dll y asociarlo en las tablas publicitarias correctas (CLSID, AppID ... ad nauseum ) al componente que contiene 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 ser completo (autorreferencial).
Todavía estoy tratando de entenderlo todo. Por supuesto, si el empaquetador captura toda la información pero no asocia la información COM al .dll, los regkeys todavía se escriben en el momento de la instalación, solo el MSI no cuida a la aplicación si las cosas van mal (que casi nunca)