Ensamblados dependientes y de interoperabilidad COM sin registro

Question

Estamos trabajando en una integración de una aplicación grande basada en MFC con un puñado de complementos administrados (.NET). La comunicación con estos complementos se realiza a través de COM.

Históricamente, acabamos de utilizar el registro para hacer estos complementos disponibles (como servidores COM) para la aplicación. Pero, ahora estamos tratando de usar interoperabilidad COM libre de registro para hacer esto.

Nos gustaría que estos complementos puedan vivir en un directorio separado del que ejecuta la aplicación, idealmente en cualquier lugar. Pero, aparentemente estamos teniendo problemas con la creación de instancias de los objetos del servidor debido a la incapacidad de resolver ensamblajes dependientes, que también viven en el directorio con la DLL del servidor COM.

La interoperabilidad COM "pasada de moda" manejó esto usando un contexto LoadFrom cuando cargó el ensamblado de destino. Pero el mecanismo de contexto de activación no parece hacer esto.

¿Alguien sabe cómo hacerlo funcionar? No está claro si podemos identificar ensamblajes dependientes en el manifiesto SxS del módulo, o quizás podemos crear el contexto de activación de manera diferente.

¡Gracias por cualquier pensamiento/sugerencia!

Jeff

Answer 1

Esperanza entiendo el problema ya que no estoy tan familiarizado con un proyecto MFC Es ni limitaciones. ¿Qué tal una clase .NET "bien conocida" con una interfaz (registrada permanentemente con la aplicación MFC) que, a su vez, maneja todas las activaciones y las instancias?

Rodney

Answer 2

¿Se ha registrado dlls intermediados (interoperabilidad) con .NET Framework?

C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm "camino .. \ AxInterop.xxx.dll" o C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm "camino .. \ Interop.xxx.dll"

Saludos Phani

Answer 3

Cuando miro el artículo en Simplify App Deployment with ClickOnce and Registration-Free COM observo que hacen referencia al nombre de archivo del registro gratuito DLL objeto COM en el manifiesto de aplicación. Supongo que este nombre de archivo podría cambiarse para incluir un directorio o algo así.

En segundo lugar, en la sección "Un ejemplo más complejo", incluyen objetos COM dependientes como referencias a su proyecto y los establece como aislados. Es decir, ahora también están libres de registro. Mi suposición es que su camino también podría ser actualizado.

Answer 4

abrir el símbolo del sistema de Visual Studio y tratar de registrar su conjunto usando regasm

regasm /tlb:"path"