I am using tlbimp.exe to create managed wrappers around some COM objects.  
Suppose I have an interface IFoo, and a second interface IBar whose methods
contain IFoo parameters.  I am finding that if I add a coclass, CFoo, that
implements IFoo, to my type library, tlbimp.exe replaces IFoo with CFoo in
IBar's method arguments.  Some code:

My IDL looks something like:

[
   object,
   uuid(...),
   dual,
   pointer_default(unique)
]
interface IFoo : IDispatch
{
   // properties, methods, etc.
};

[
   object,
   uuid(...),
   dual,
   pointer_default(unique)
]
interface IBar : IDispatch
{
   [id(1)] HRESULT DoSomething([in] IFoo* pFoo);
};

[
   uuid(...),
   version(1.0)
]
library Test
{
   importlib("stdole32.tlb");
   importlib("stdole2.tlb");

   [
       uuid(...)
   ]
   coclass CFoo
   {
       [default] interface IFoo;
   };
};

If I use tlbimp.exe to generate an interop assembly based on the resulting
type library, the prototype for IBar.DoSomething (as viewed in ildasm.exe)
will look like:

DoSomething : void(class TestLib.CFoo)

If I remove the coclass from the IDL, it will look like:

DoSomething : void(class TestLib.IFoo)

The second prototype is obviously what I want.  This seems like a bug in
tlbimp.exe--why should the presence of a coclass that uses a given interface
affect method prototypes in unrelated interfaces?  I have read through the
tlbimp.exe documentation and can't find any way to work around this behavior.
I have resorted to using awkward factory methods instead of coclasses for
the time being.  Can anyone comment on this?

Thanks...