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

Question

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

Answer 1

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.