469,934 Members | 2,049 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,934 developers. It's quick & easy.

regasm exports unmanaged classes

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
Nov 17 '05 #1
5 1630
Added a more directly appropriate newsgroups and set follow-ups to that
newsgroup.

Ronald Laeremans
Visual C++ team

"Anthony Evans" <ae********@yahoo.com> wrote in message
news:86*************************@posting.google.co m...
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

Nov 17 '05 #2
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

"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message news:<er**************@tk2msftngp13.phx.gbl>...
Added a more directly appropriate newsgroups and set follow-ups to that
newsgroup.

Ronald Laeremans
Visual C++ team

"Anthony Evans" <ae********@yahoo.com> wrote in message
news:86*************************@posting.google.co m...
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.


<snip>
Nov 17 '05 #3
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" <ae********@yahoo.com> wrote in message
news:86*************************@posting.google.co m...
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

"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:<er**************@tk2msftngp13.phx.gbl>...
Added a more directly appropriate newsgroups and set follow-ups to that
newsgroup.

Ronald Laeremans
Visual C++ team

"Anthony Evans" <ae********@yahoo.com> wrote in message
news:86*************************@posting.google.co m...
> 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.
>


<snip>

Nov 17 '05 #4
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.
Nov 17 '05 #5
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.
Nov 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Namratha Shah \(Nasha\) | last post: by
6 posts views Thread by marek | last post: by
2 posts views Thread by Id L | last post: by
6 posts views Thread by Stephen Walch | last post: by
9 posts views Thread by Amit Dedhia | last post: by
2 posts views Thread by Jon Slaughter | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.