Search code examples
c#visual-studiocominteropcom-interop

Is it possible to test a COM-exposed assembly from .NET?


I have a .NET assembly which I have exposed to COM via a tlb file, and an installer which registers the tlb. I have manually checked that the installer works correctly and that COM clients can access the library. So far, so good...

However, I am trying to put together some automated system tests which check that the installer is working correctly. As part of that I have automated the installation on a VM, and I now want to make some calls to the installed COM library to verify that it is working correctly. I originally thought about writing some tests in VB6, but I already have a large suite of tests written in C#, which reference the .NET assembly. I was hoping that I could change these to reference the .tlb, but I get an error when I try this within VS2008:

The ActiveX type library 'blah.tlb' was exported from a .NET assembly and cannot be added as a reference.

Is there any way I can fool VS2008 into allowing me to add this reference, perhaps by editing the tlb file?

Googling hasn't come up with any solutions. All I've found is a Microsoft Connect article stating that this is "By Design": http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=120882


Solution

  • The Closest I've gotten to a solution is something like the following:

    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))
        }
    }
    

    It's not very pretty, but I think gets the point across. You could of course put the ComObject instantiation into a constructor and wrap the rest of the calls to the object, but probably not necessary for test code.