Gotcha re-implementing interfaces

I've recently stumbled upon a problem that a couple of VSIP Developers have encountered. 
I say 'a couple' because it required two packages interacting in order to discover
the real problem.

Basically a managed package derived from the base Package class in the VSIPHelper
base class and also re-implemented the IOleCommandTarget interface.  This confuses
the CLR interop code.  The most common effect of this is that the base class
always gets called on the interface when called from unmanaged code. (The derived
class implementation is never called).  The worst case could be that it is indeterminate
if the base class will be called or the derived class. 

The really bad thing is that there appeare to be cases where the vtable offset
of the interface appears to be cached.  So, depending on the behavior above,
you could get random functions called since the vtable for derived objects could be
different (depending on the class hierarchy).  The offset for one package not
overriding the implementation is different than the offset for another package which
does override the implementation.  If the first one to be called causes the offset
to be stored.  The second one to be called loses because a random place in the
vtable will be called.

The bottom line for VSIP developers is: Don't re-implement interfaces already implemented
by a base class. 

In Everett Extras we provide a virtual method for each IOleCommandTarget method so
that you can override the behavior of the base class and continue to rely on its implementation
of the interface.

In VSI Everett Extras, if you find the need to override the base implementation of
some other interface, but we don't provide a way like with IOleCommandTarget, please
let me know.

Thanks, Allen