Quote Originally Posted by Schmidt View Post
I already tried to explain it to you...
But again, ... maybe it will sink in this time...

VB6 and modern Office-VBA (when they check in COM-Dlls, parsing their typelibs) -
are usually satisfied with parsing the Default-Interfaces of an (imported) COM-Dll-Class.

If such a parsed Class *also* implements "additional interfaces", these are (AFAIK) left to compiler-evaluation -
(when a "Left-Hand-side" assignment enters the game, involving a COM-TypeCast via QueryInterface - "away" from the default-interface, to an implemented one).

So yes, I think the developers of the MS-devs of these true COM-tools (Office-VBA, VB6, VBScript) knew what they were doing
(with regards to TypeLib-parsing of COM-Dlls) - whilst the .NET-guys who wrote the Typelib-parser for .NET-imports did not.

So, the .NET-Typelib-parser complains (with a warning, not an error) about some incorrect stuff in
an Interface-lib (an MS-one: VB6.olb), which is indirectly addressed via [Implements Printer] in one of the exposed Classes of the RC-lib
(but Types of that interface are not part of the default-interface of that Class which implements this secondary Printer-interface).

So, if 3 MS-Tools (as well as TwinBasic) do it right - and one MS-Tool (the .NET Typelib-parser) has problems -
who do you think is to blame?

In either case your bug-report has to go to MS (not to the Author or the RichClient):
1) for "overzealous" TLB-parsing when importing complex COM-libs (due to pre-scanning secondary implemented types)
2) and additionally you might kindly ask to fix the "warning-message-causing MS-VB6.olb"

Despite that (all being MS-VS2019 .NET problems) - I'm not a VS2019-user - so I don't even know if you're using your tool correctly.
I'd suggest you ask questions about that in a VS2019-group - here we're talking about VB6 and its COM-tools.

Olaf
I'll concede this to you as the resident COM expert. But hey, I have never seen any of the well known COM libraries fail like this with .Net. Something is wrong somewhere.

Quote Originally Posted by Schmidt View Post
I'm not a VS2019-user - so I don't even know if you're using your tool correctly.
You might be 100% correct here, even so, it still says a lot that I didn't require any special knowledge to get .Net to work with Office, or even ADO. I don't think Microsoft intended every developer wanting to use a COM library also be a COM expert. I mean I'm more technically proficient than your average front-end developer just getting by doing basic tasks and this problem is beyond even my capabilities. Do you think Microsoft intended this? Perhaps we just got a clue about why Microsoft abandoned COM as their underlying object model for Visual Basic.

You know, come to think of it, I have had countless problems like this with COM over the entire 10+ years when I was a VB6 programmer, especially when it comes to deploying them in the wild. I have never and I stress, never had these kinds of problems with .Net. COM is too fragile and breaks too damn easily. Removing COM as the foundational object model was the best thing Microsoft ever did for Visual Basic. This little experience only strengthens my resolve on .Net being a better development platform than VB6.