2008-12-15 30 views
11

Tengo un ensamblado .NET que he expuesto a COM a través de un archivo tlb, y un instalador que registra el tlb. He comprobado manualmente que el instalador funciona correctamente y que los clientes COM pueden acceder a la biblioteca. Hasta ahora, tan bueno ...¿Es posible probar un ensamble expuesto a COM de .NET?

Sin embargo, estoy tratando de armar algunas pruebas automáticas del sistema que verifiquen que el instalador esté funcionando correctamente. Como parte de eso, he automatizado la instalación en una VM, y ahora quiero hacer algunas llamadas a la biblioteca COM instalada para verificar que esté funcionando correctamente. Originalmente pensé en escribir algunas pruebas en VB6, pero ya tengo un gran conjunto de pruebas escritas en C#, que hacen referencia al ensamblado de .NET. Esperaba que pudiera cambiarlos para hacer referencia al .tlb, pero aparece un error cuando intento esto en VS2008:

La biblioteca de tipos ActiveX 'blah.tlb' se exportó de un ensamblado .NET y no se puede agregar como una referencia.

¿Hay alguna manera de engañar al VS2008 y permitirme agregar esta referencia, quizás editando el archivo tlb?

Google no ha encontrado ninguna solución. Todo lo que he encontrado es un artículo de Microsoft Connect indicando que éste es "por diseño": http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=120882

+0

Un par de personas han mencionado el uso de tlbimp.exe. Si intento tlbimp.exe blah.tlb obtengo el error: "La biblioteca de tipo blah se exportó desde un ensamblado CLR y no se puede volver a importar como un ensamblado CLR". – Akash

Respuesta

12

Lo más cerca que he llegado a una solución es algo parecido a lo siguiente:

using System; 
class ComClass 
{ 
    public bool CallFunction(arg1, arg2) 
    { 
     Type ComType; 
     object ComObject; 

     ComType = Type.GetTypeFromProgID("Registered.ComClass"); 
     // Create an instance of your COM Registered Object. 
     ComObject = Activator.CreateInstance(ComType); 

     object[] args = new object[2]; 
     args[0] = arg1; 
     args[1] = arg2; 

     // Call the Method and cast return to whatever it should be. 
     return (bool)ComType.InvokeMember("MethodToCall", BindingFlags.InvokeMethod, null, ComObject, args)) 
    } 
} 

No es muy bonito, pero creo que se entiende bien. Por supuesto, puede poner la instanciación de ComObject en un constructor y ajustar el resto de las llamadas al objeto, pero probablemente no sea necesario para el código de prueba.

+0

+1 para el método Type.GetTypeFromProgID, puede obtener COM tipo. Intenté esto, funciona (pero ¿hay alguna diferencia práctica al agregar directamente una referencia? No lo sé). – peenut

+0

'methodCOM' en el ejemplo debería ser de hecho la variable' ComType'. – glebd

-1

Usando tlbimp.exe puede generar un ensamblado de su componente COM que se puede utilizar en el código .NET

+2

No si el componente COM se creó en C# u otro lenguaje .NET –

+2

-1 razón igual que el comentario: No si el componente COM se creó en C# u otro lenguaje .NET – peenut

0

Debe estar capaz de crear una clase contenedora para su componente COM instalado utilizando TLBImp y luego ejecutar sus pruebas contra eso. Básicamente, estará escribiendo un ensamblado .Net, instalándolo en COM y luego probando en la clase contenedora para que sus pruebas se enruten como si fuera llamado por un componente COM

Cuestiones relacionadas