2010-03-02 23 views
7

¿Es posible encontrar todas las interfaces (clases, parámetros, etc.) normalmente registradas con TypeLib del Modelo de Objetos Componentes (COM) aunque el TypeLib esté completamente vacío? Si es así, ¿cómo harías para hacer esto? Creo que otro término para esto es un "COM anónimo". Estoy seguro de que existen interfaces accesibles para este COM porque tengo una aplicación que está utilizando una clase que no está en la lista en el TypeLib.¿Cómo se encuentran las interfaces de un COM sin typelib?

Respuesta

8

Si la biblioteca de tipos está en blanco, no hay forma de que pueda encontrar información sobre los tipos en una biblioteca COM.

Necesita al menos una entrada de coclass en el typelib para encontrar una implementación de IUnknown.

Si tiene eso, entonces puede crear instancias de la clase y luego llamar al QueryInterface en IUnknown para la implementación IDispatch (si existe).

Si existe una interfaz IDispatch, puede llamar al GetTypeInfo para obtener información sobre las interfaces que se implementan.

Si necesita realizar llamadas con destino tardío a IDispatch, deberá llamar al Invoke method.

Tenga en cuenta que menciona la biblioteca de tipos, pero es una práctica común para los servidores COM en proceso incorporar la biblioteca de tipos en la DLL que es la implementación de los tipos representados en la biblioteca. ¿Estás seguro de que no has verificado eso también? ¿O estás seguro de que tienes la biblioteca de tipos y está en blanco?

Si el tipo lib está realmente en blanco y el dll no lo contiene, es completamente posible que el tipo lib sea "privado" en el sentido de que otros clientes se compilaron en su contra. COM no necesita necesariamente un tipo lib en tiempo de ejecución. El patrón para exponer las implementaciones IClassFactory interface es exportar una función DLL estándar con una firma conocida.

Se podría llamar fácilmente al LoadLibrary, luego llamar al GetProcAddress y enviar el resultado a IClassFactory. A partir de ahí, utilizarían el GUID privado y el IID que conocen (no de la biblioteca de tipos), así como las interfaces COM que han definido de forma privada y trabajan desde allí.

El único razonamiento que se me ocurre para algo como esto es una forma de ofuscación y/o abordar problemas de privacidad/seguridad, solo permitiendo a los clientes que el productor del servidor apruebe llamarlo.

No lo ayuda, pero podría explicar por qué está viendo una biblioteca de tipos sin información y al mismo tiempo, ver a otros clientes consumir la biblioteca.

+0

Gracias por la respuesta rápida, tendré que hacer un poco más de excavación. Pero sí, estoy seguro de que TypeLib está incompleto porque tengo un programa que está accediendo a una clase en el COM que no está en el TypeLib. – rook

+0

@ The Rook: actualicé mi respuesta para reflejar los motivos por los que podría estar viendo este comportamiento. – casperOne

5

No es común el uso de una biblioteca de tipos en la programación COM. Cualquier lenguaje de scripting lo hace, usa IDispatch para descubrir métodos y propiedades compatibles en tiempo de ejecución. IDispatch :: GetIDsOfNames() o IDispatch :: GetTypeInfo() hace rodar esa bola. Esto se llama enlace tardío. Es lento, pero eso no importa en un lenguaje de scripting.

Otra forma estándar es mediante archivos de encabezado generados por MIDL desde un archivo .idl que describe las interfaces y coclasses. Encontrará muchos de ellos en el directorio de inclusión de Windows SDK, mshtml.h, por ejemplo. Pero esto solo es adecuado para el código C/C++ no administrado.

Usar COM sin una biblioteca de tipos en un lenguaje administrado como C# es difícil pero no imposible. VB.NET es el mejor lenguaje, admite el enlace tardío de fábrica.C# mejorará cuando llegue la versión 4.0, tiene una nueva palabra clave "dinámica".

Cuestiones relacionadas