You gotta love this stuff, it's a fight and a trip to learn to surf the waves.

Take Interop ... set the <ComClass()> attribute to some hand-made guids for the class, interfaces and events and you'll never again "lose" the guids in later compiles.

Happily you go.

Then you make the app a bit more robust and do an Interop compile and BOOM: "COM Interop registration failed. Error loading type library/DLL"

But.. it worked ... wait ... huh?

Although most every NG answer mentions that a re-regasm of the visualbasic.dll will solve the problem (because it is wrongly assumed that every lowly vb dev naturally is using something from the VB6 compatibility layer - not the best habit to get into), that ain't the ticket.

Seems if your COM exposed classes in the dll implement any .net interfaces in a separate .net dll you get that helpful error, even if don't want the COM app to call the .net interfaces (and if you did you would have made them interopable.)

Here's the deal: if dllONE is to be COM-callable and is failing the compile, look for custom .net interfaces defined in any other dlls that it references. Go into those projects, and add <ComVisible(False)> to their Assembly.vb file.

MOOB, problem goes away.

Robert Smith
Kirkland, WA

added September 2002