regasm exports unmanaged classes

[Anthony Evans]

Greetings

I'm using VC++.NET to create a class library. The class library
contains managed classes that wrap legacy unmanaged classes by the
same name.

I use regasm to register the DLL for COM interop.

If I don't include any managed classes in the library, the context
help in VB6 lists every single unmanaged class in the class library
(even though those classes are not declared with the public keyword.)

If I include managed classes in the class library (in addition to the
aforementioned unmanaged ones), the context help in VB6 lists only the
managed classes.

If the managed classes have the same names as the unmanaged classes,
the VB6 context help shows the class name with the library name and an
underscore prepended (eg: MyLibrary_MyClass instead of MyClass), and
as before, does not show the unmanaged ones (which seems to defeat the
purpose of resolving the name collision in this manner).

When I say "context help", I mean when I type

Dim x As MyLibrary. <-- right here, VB6 lists the available classes

When I run regasm in verbose mode, it happily declares that it is
exporting every class in the class library, including the old
unmanaged ones that are, I assume implicitly scoped as "private".

How do I tell regasm (or VC++.NET 2003 or whatever) to only export the
classes marked as public and thus, not to attempt to resolve name
collisions with underscores?

Thanks in advance.

Tony

 

[Ronald Laeremans [MSFT]]

Added a more directly appropriate newsgroups and set follow-ups to that
newsgroup.

Ronald Laeremans
Visual C++ team

 

[Anthony Evans]

Hello Ronald

Thank you for your efforts, however I actually posted to languages.vc
first. No one has responded to my original thread there.

Tony

Added a more directly appropriate newsgroups and set follow-ups to that
newsgroup.

Ronald Laeremans
Visual C++ team

<snip>

 

[Ronald Laeremans [MSFT]]

I redirected this to the interop newsgroup. Which is where the experts on
this hang out., including the team that wrote regasm.

Ronald

 

[Anthony Evans]

I spoke with David King, a Volt contractor at Microsoft Product
Support.

He told me that this was a "known limitation of the compiler." He
suggested the following work-arounds:

1. Modify the source components to avoid creating the problem in the
first place. This is the most robust, and recommended, solution. For
example, choose sufficiently unique names for public symbols, given
the preceding information. Creating .NET components that work well
when exposed to COM clients usually involves some compromises (e.g.
anticipating the flattening of namespaces).

2. Modify client usage of the resulting library.
a) The C++ #import statement allows selective renaming of imported
symbols: #import "msrepro.dll" rename ("msrepro_Class1", "Class1")
b) VB6 (and other) clients have no such option.

3. Forego automated wrapper (interop) generation and write your own
COM-callable wrapper library. VC++ 7.1 supports mixed
managed/unmanaged code that would allow you to directly use a .NET
library from within a ‘traditional' C++ COM library, which would then
expose it's own interface to bridge COM clients to the .NET DLL.

4. Modify the exported type library. The only way to do this is to
decompile the type library to IDL, modify it (e.g. rename symbols),
and recompile. tlbexp.exe, any text editor and midl.exe may be used to
perform each of these actions, respectively.

I'll probably go with #4. I'll post back here if it doesn't work.

 

[Anthony Evans]

I spoke with David King, a Volt contractor at Microsoft Product
Support.

He told me that this was a "known limitation of the compiler." He
suggested the following work-arounds:

1. Modify the source components to avoid creating the problem in the
first place. This is the most robust, and recommended, solution. For
example, choose sufficiently unique names for public symbols, given
the preceding information. Creating .NET components that work well
when exposed to COM clients usually involves some compromises (e.g.
anticipating the flattening of namespaces).

2. Modify client usage of the resulting library.
a) The C++ #import statement allows selective renaming of imported
symbols: #import "msrepro.dll" rename ("msrepro_Class1", "Class1")
b) VB6 (and other) clients have no such option.

3. Forego automated wrapper (interop) generation and write your own
COM-callable wrapper library. VC++ 7.1 supports mixed
managed/unmanaged code that would allow you to directly use a .NET
library from within a ‘traditional' C++ COM library, which would then
expose it's own interface to bridge COM clients to the .NET DLL.

4. Modify the exported type library. The only way to do this is to
decompile the type library to IDL, modify it (e.g. rename symbols),
and recompile. tlbexp.exe, any text editor and midl.exe may be used to
perform each of these actions, respectively.

I'll probably go with #4. I'll post back here if it doesn't work.