Fuerza la interoperabilidad de .NET para utilizar el DLL COM local

Question

¿Es posible forzar un ensamblado de interoperabilidad para hacer referencia a una copia local de su DLL COM asociada?

Este es el escenario:

Tengo una aplicación .NET que hace referencia a un ensamblado de interoperabilidad (Interop.OTAClient.dll), que es la interoperabilidad de un archivo DLL COM (OTAClient.dll, que es la API de automatización para HP Quality Center). No soy muy conocedor de COM, pero según tengo entendido, el conjunto de interoperabilidad busca las clases COM mediante referencias GUID en el registro, en lugar de apuntar a un archivo específico.

El problema que tengo es que la copia de OTAClient.dll a la que apuntan las claves del registro se sobreescribe por diferentes versiones, dependiendo de la versión de QC en la que acabe de iniciar sesión en un navegador, y las diferentes versiones de estos archivos DLL no son compatibles entre ellos La aplicación .NET solo se conectará a una versión específica de QC, por lo que no puedo hacer que la DLL COM varíe de esta manera.

Cualquier sugerencia sería muy apreciada, ya que este comportamiento es realmente irritante. He visto otras preguntas sobre problemas de interoperabilidad COM, pero parece que se trata de forzar una versión local de la DLL de interoperabilidad para ser utilizada en lugar de una en el GAC, en lugar de este escenario particular que involucra la DLL COM real.

Answer 1

Quiere Registration-free COM.

Answer 2

Pavel me apuntó en la dirección correcta, por lo que marcaré la suya como la respuesta. Para el beneficio de todos los demás, esto es lo que hice:

1. Agregué una referencia al archivo OTAClient.dll original y dejé que Visual Studio generara la biblioteca de interoperabilidad.
2. Haga clic con el botón derecho en la biblioteca a la que se hace referencia en el Explorador de soluciones y haga clic en Propiedades. Luego configure Aislado a Verdadero. Esto hace que VS genere un archivo de manifiesto que le indique a su programa que busque localmente su biblioteca COM en lugar de la lista en el registro.
3. Específico para mi escenario: también tuve que hacer referencia a WebClient.dll desde Quality Center y establecer Isolated to True para eso también. Esto no lo usan directamente las aplicaciones que usan la API de OTA, pero parece que OTAClient.dll hace referencia a él.

De esta manera, puede iniciar o cerrar sesión en las instancias de QC cuyas versiones difieren de la utilizada por su aplicación sin romperla. En mi caso, tengo una instancia de QC local que es v9 y que se utiliza para la automatización específica del proyecto (por diversas razones, está muy personalizada para satisfacer nuestras necesidades, tiene mucho espacio para el almacenamiento de captura de pantalla, etc.) y a la que se conecta mi aplicación. Sin embargo, para las pruebas manuales también necesito iniciar sesión usando IE en una instancia v9.2 ubicada en otro lugar. Si hubiera iniciado sesión previamente en la instancia de v9.2, tendría que abrir la instancia de v9 en IE y dejar que vuelva a descargar los controles antes de volver a ejecutar mi aplicación ... y ahora no. :)

Answer 3

Un pequeño ejemplo que muestra cómo cambia Web.config después de establecer la propiedad Aislada en verdadero, ayudaría a otros a entender lo que está sucediendo en la parte de atrás cuando establezcamos la propiedad Aislada como verdadera. VS realmente ingresa algunas líneas en su código, de modo que utilizará com Dll de CLSID específico.

Actualmente tengo dos aplicaciones .Net en el mismo servidor, donde una aplicación usa el centro de calidad 10.0 Dll y la otra se actualiza al centro de calidad ALM 11.0. Entonces, en el mismo servidor no podemos registrar una DLL con el mismo nombre.