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