http://msdn2.microsoft.com/en-us/library/ms364069(vs.80).aspxWriting code that is fully interoperable with two different runtimes can blow; 'nuff said. The single-most valuable thing to remember when doing COM interop (in my opinion) is to add your damn .NET module to the GAC. Why?
The reason lies in the internals of COM, and if you've ever had the distinct pleasure of pounding your head against the desk while working on COM you'll quickly understand what I'm trying to say. COM was built with the ideals of interoperability in mind: so long as the two, distinct components stuck to a particular contract-based communcation (through "interfaces") then everything worked nicely.
In COM to get at a particular bit of functionality (which is exposed via an "interface") you must get at the Com Class (coclass) which implements the interface. A particular COM server houses the Com Class (coclass) which implements the interface. Basically, to get at functionality, then, you must locate the physical module, then ask the physical module to activate a particular "object" and then ask the "object" for an interface pointer to the functionality; the rest is done through vtable pointer arithmetic (this is all if you're using "IUnknown" semantics, otherwise the game is slighty different).
.NET interops with COM by having the mscorlib.dll module be the server - it is responsible for loading the necessary DLL files that implement your .NET functionality and doing all the proper dirty work of interoperating with COM. Say you have a COM plugin, then, for some application - but the plugin is written in VB.NET. The main application attempts attempts to create a com instance (through CoCreateInstance()) of your .NET module - this routes the COM runtime to Mscorlib.dll which attempts to locate your DLL; however, how does Mscorlib.dll find it? Well, if you haven't placed it directly next to (in the same directory as) the main application or in the GAC, MScorlib.dll will not be able to find your module and you're, effectively, "dot screwed".
....by placing the module in the GAC you'll be able to guarantee mscorlib.dll will find your module.
