Why does accessing a COM object from .NET, without going through the Interop class, sometimes work?

Question

When you interface a COM object from .NET code, VS creates an interop DLL, with interop classes.

Example:

You have a foo.dll the implements a COM library Foo, that includes an implementation of the COM interface "IBar". You add a reference to foo.dll to a .NET project. in /bin, you'll see an Interop.FooLib.dll. In the Object Browser, you'll see Interop.FooLib, under that you'll see FooLib, under that you'll see BarClass, under that you'll see Base Types, under that Bar and IBar.

In your .NET code, when declaring a variable, you can type FooLib, and intellisense will give you the options of either Bar or BarClass().

From what I understood, it really doesn't matter which you use in a variable declaration, but it very much does matter which you used for its constructor.

That is, both of these should work:

FooLib.BarClass theBar = new FooLib.BarClass();
FooLib.Bar theBar = new FooLib.BarClass();

But this shouldn't work:

FooLib.Bar theBar = new FooLib.Bar();

Here's the problem. We just tracked down an odd bug, where code that was working for some customers, and worked in our development and testing environments, did not work at one customer site, turned out to have been a programmer using the Bar() constructor.

So, can anyone explain exactly what the difference is between the two constructors, Bar(), and BarClass()?

Can anyone explain why the Bar() constructor seems to work, sometimes?

Can anyone provide a method for ensuring that no one is mistakenly calling the wrong constructors, without reading every line of code?

-- ADDED --

It was suggested that the problem was in our COM implementation. This is what we're doing:

The IDL:

[
    object,
    uuid(...),
    dual,
    helpstring("IBar Interface"),
    pointer_default(unique),
    nonextensible
]
interface IBar : IDispatch
{
    [id(1), helpstring("method barify")] 
        HRESULT barify([out, retval] VARIANT_BOOL *rVal);
    // ...
};
// ...
[
    uuid(...),
    version(1.0),
    helpstring("Foo 1.0 Type Library")
]
library FooLib
{
    importlib("stdole32.tlb");
    importlib("stdole2.tlb");
    // ...
    [
        uuid(...),
        helpstring("Bar Class")
    ]
    coclass Bar
    {
        [default] interface IBar;
    };
    // ...
};

The Implementation:

class ATL_NO_VTABLE CBar : 
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CBar, &CLSID_Bar>,
    public IDispatchImpl<IBar, &IID_IBar, &LIBID_FooLib>,
    public ISupportErrorInfoImpl <&IID_IBar>
{
public:
    CBar();

    DECLARE_REGISTRY_RESOURCEID(IDR_BAR)

    DECLARE_PROTECT_FINAL_CONSTRUCT()

    BEGIN_COM_MAP(CBar)
        COM_INTERFACE_ENTRY(IBar)
        COM_INTERFACE_ENTRY(IDispatch)
        COM_INTERFACE_ENTRY(ISupportErrorInfo)
    END_COM_MAP()

    // ...
};

-- ADDED LATER --

Decompile*, via .NET Reflector:

[ComImport, CoClass(typeof(BarClass)), Guid("...")]
public interface Bar : IBar
{
}

*I don't care that the Reflector UI calls this a disassembly - if it's outputting a HLL, it's a decompile.

Answer 1

Great question. Many people are surprised this works at all because Bar is an interface and surely you shouldn't be able to create a new instance of an interface! But although I can't seem to find any specifics of the implementation, I remember reading in Adam Nathan's COM interop book that C# makes a special exception for COM interfaces marked with a CoClassAttribute and turns the call into an instantiation of the coclass instead.

But I don't know why it would sometimes work and sometimes not work.