With further investigation, I also find that: attempting to instantiate the
COM object using this code fails with "771A6CA6-937C-4593-BF1B-C4CB81F3EECA
is either not valid or not registered"

   [ComImport,
   Guid("771A6CA6-937C-4593-BF1B-C4CB81F3EECA")]
   public class CPullSource
   {
   }

  CPullSource cps = new CPullSource();

Even though I use this format all the time for creating instances of
unmanaged COM objects.  Note that this code DOES work:

   Guid g3 = new Guid("771A6CA6-937C-4593-BF1B-C4CB81F3EECA");
   Type comtype2 = Type.GetTypeFromCLSID(g3);
   object oo = Activator.CreateInstance( comtype2);

In summary: It almost looks like the managed client is using the managed COM
object as more of an assembly then a true COM object.  I'm sure that does
great things for performance and all, but it is just not going to work for
my application.

Is there some way to "cut the cord" between the client and the COM object?
I need the managed client to treat the managed COM object the same way it
treats unmanaged COM objects.  And I need to do this by changing the COM
object, rather than the clients.

I'm using vs 2003, but 2005 is an option if it will solve these
problems.

It's not clear to me that this will work - you're trying to connect a
runtime callable wrapper to a Com callable wrapper, and I don't believe this
is a supported scenario. You have managed client code calling a (managed)
interop assembly calling a CCW generated to let unmanaged code call a
managed Com client. I don't know how to break that chain without changing
the client code (by using late binding or having the client call an
unmanaged Com Dll as a shim).

I'm not at all sure this is what you're talking about, but I have a managed
class (a collection) which instantiates (and then "collects") different COM
servers. Some of the COM servers are unmanaged (written in C++ using
MFC/ATL) and some of them are managed (written in C# in the same assembly as
the client collection object even).

The way I made this work was to define the interface above the managed
server class base class. Then the unmanaged COM servers implement that
interface as acquired via an "#import" statement of the managed tlb file.

Managed servers:

// define interface
public interface IFoo
{
   string Bar
   {
       get;
   }
};

// define managed class which implements interface defined above
class ManagedFoo : public IFoo
{
   string Bar
   {
       get { return "asdg"; };
   }
};

Then my collection client app creates these things (regardless of whether
they were managed or unmanged) by using their ProgID:

string strProgId = "MyNamespace.ManagedFoo";
// or "MyNamespace.UnmanagedFoo" for the unmanaged flavor

Type typeFoo = Type.GetTypeFromProgID(strProgId);
IFoo rThing = (IFoo) Activator.CreateInstance(typeFoo);

Now the managed client can play with both managed and unmanaged servers
according only to the interface definition.

I specifically remember there was no way to do this without the interface
definition, because there was no way I could get the managed client to think
of the unmanaged servers as being of type ManagedFoo (i.e. a .Net class
definition). So the "least common denominator" was the COM interface, which
.Net supports the specifying of via "interface" definitions.

Bob