OK, maybe it's a little early to find design patterns, considering this is so
new.  But ideas are welcome.

The basic idea is to provide glue code between unmanaged C++ components and the
.NET framework.

What I've been reading so far suggested the best approach is to use managed
C++.  So far that idea has panned out fairly well.  There have been some
gliches; never-the-less, the concept has been proved.

I'm starting to refine the approach and need some ideas.

One area I'm concerned about is this.  Suppose every managed class has a
container to an unmanaged class.  What's the best way to make this ptr
accessible to other glue code without making it available to the whole world?
When I say "make this ptr accessible" I mean provide methods on classes that
either allow objects to get created from ptrs or return those ptrs.  Basicly, I
want to hide the whole ptr to object relationship from other .NET code, while
not hiding this relationship from managed code.  This design pattern will be
automated and enforced on components that haven't even been written yet.  So
certain assumptions about relationships between managed code might not apply.
For instance, suppose the managed code was written in Java.  Java has its own
access modifiers.  One possibility would be to mark everything with package
access.  But there is no way to know that future components will be in the same
package.  The problem here is different because the language is different, but
the concept is pretty much the same.  Will namespaces work?  Is there a way
scope method access to namespaces?

Other areas will need to be flushed out as well.  Any insight into patterns that
are taking shape would be greatly appreciated.

Carl