Building VB.NET Interface definitions from a COM interface

[Rob Perkins]

Hi,

Is there anything out there which can take either a COM interface
definition as an input, or a VB6 class file as an input, and return a
..NET Interface definition block as an output?

I need to refactor a block of VB6 code, and the converters built into VS
2005 aren't working at all for me.

Rob

[Tom Shelton]

Rob Perkins wrote:

Hi,

Is there anything out there which can take either a COM interface
definition as an input, or a VB6 class file as an input, and return a
.NET Interface definition block as an output?

I need to refactor a block of VB6 code, and the converters built into VS
2005 aren't working at all for me.

Rob

What seems to be the problem Rob? There are command line utilities
(tlbimp.exe) that can take a dll or type lib and convert them into .NET
RCW's. You can also go the other way with tlbexp.exe.

VS will do this for you automatically if you reference the compiled VB6
dll...

Or are you just trying to convert the actual code? If that's the case
- and the converters are having issues with it, then you may need to do
a re-write there....

--
Tom Shelton [MVP]

[Rob Perkins]

Tom Shelton wrote:

Rob Perkins wrote:

Hi,

Is there anything out there which can take either a COM interface
definition as an input, or a VB6 class file as an input, and return a
.NET Interface definition block as an output?

I need to refactor a block of VB6 code, and the converters built into VS
2005 aren't working at all for me.

Rob

What seems to be the problem Rob? There are command line utilities
(tlbimp.exe) that can take a dll or type lib and convert them into .NET
RCW's. You can also go the other way with tlbexp.exe.

VS will do this for you automatically if you reference the compiled VB6
dll...

No no, I'm aware of those. However, I discovered a circular reference
situation which makes me uncomfortable where I have a COM DLL containing
four COM interfaces, one of which is referenced by my .NET assembly.

The .NET assembly, in turn, references the interfaces on the COM DLL. It
has not failed to work, but it has made debugging... interesting.

I can resolve it by refactoring one of the COM classes into a .NET
class, and I've found that the code conversion stuff doesn't really work
that well on the whole class, though it works just fine on snippets of
code from the class, without telling me which part of the class it's got
trouble with.

Therefore, if I can produce a (rather complex) .NET *interface* for the
COM code, and expose that to COM, along with a .NET implementation
class, I can resolve the circular reference problem which is giving me
fits.

Make sense?
Or are you just trying to convert the actual code? If that's the case
- and the converters are having issues with it, then you may need to do
a re-write there....

A rewrite is basically what I'm doing, natch. But the rewrite must in
turn expose its interface to COM, which is why I wanted to duplicate, as
much as possible, what I already had. The snippet converter in the tools
menu has no problem with most of the class, but it won't tell me which
part of the class it has problems with, since the machine just enters
some kind of race condition, whose only exit is a forced termination of
the devenv process.

Rob

[Rob Perkins]

No no, I'm aware of those. However, I discovered a circular reference
situation which makes me uncomfortable where I have a COM DLL containing
four COM interfaces, one of which is referenced by my .NET assembly.
By that I mean that the COM DLL references an interface on the .NET
assembly.

The .NET assembly, in turn, references the interfaces on the COM DLL. It
has not failed to work, but it has made debugging... interesting.

The .NET assembly in turn references *different* interfaces on the COM DLL.

Rob