Com Interop Check List

[Frank Rizzo]

I am writing a library in .net that will be used by VB6 clients.

I initially wrote the library,
generated a strong key (via sn –k mykey.snk),

added it to AssemblyInfo.vb class (via <Assembly:
AssemblyKeyFile("c:\tgol\phpclass\mykey.snk")> statement),

registered assembly in the registry (via regasm
c:\code\project\bin\myassembly.dll /tlb:myassembly.tlb command),

added the assembly to the GAC (via gacutil /i
c:\code\project\bin\myassembly.dll)

I was then able to use it from my VB6 project, however, I wasn't getting
intellisense on my classes. Someone mentioned that this is because by
default, .NET classes only expose the auto-dispatch interface which is
not readable by VB6. So I added
<ClassInterface(ClassInterfaceType.AutoDual)> attribute to all my
classes and now I get the intellisense.

My question is whether this is all I have to do to make sure that my
..NET assembly will behave fine when used from VB6.

Thanks.

 

[Rob Teixeira [MVP]]

Looks like you got everything.
Just be careful of argument/return type usage where there isn't a one-to-one
match with VB6 (COM) types, for example date, currency, and boolean. Dates
are handled slightly differently in COM/VB6, currency/decimal have different
ranges, and boolean in .NET = 1 or 0, whereas in VB6 it's 0 or -1 (only
matters if you are trying to do numeric conversions to int). Also avoid
passing generic Object/Variant types back and forth where possible. By all
means, avoid passing variant arrays of variants (object ref containing
object arrays), as the marshalling overhead quickly becomes staggering.
Other than that, you should be good to go.

On a final note, and this might get a little more complicated (but IMO,
worth the effort)... rather than using ClassInterface, you might want to
consider actually creating public interfaces in .NET, and exposing those to
COM, then creating classes in .net that implement those public interfaces.
The ClassInterface(AutoDual) attribute gets you quick results for little
effort, but it gets sticky if you have to recompile and re-version your
assembly. By explicitly and manually creating interfaces (and assigning
GUIDs), you can properly maintain the assembly and reduce the impact on the
VB6 clients.

-Rob Teixeira [MVP]

 

[Frank Rizzo]

Looks like you got everything.
Just be careful of argument/return type usage where there isn't a one-to-one
match with VB6 (COM) types, for example date, currency, and boolean. Dates
are handled slightly differently in COM/VB6, currency/decimal have different
ranges, and boolean in .NET = 1 or 0, whereas in VB6 it's 0 or -1 (only
matters if you are trying to do numeric conversions to int). Also avoid
passing generic Object/Variant types back and forth where possible. By all
means, avoid passing variant arrays of variants (object ref containing
object arrays), as the marshalling overhead quickly becomes staggering.
Other than that, you should be good to go.

Thank you.

On a final note, and this might get a little more complicated (but IMO,
worth the effort)... rather than using ClassInterface, you might want to
consider actually creating public interfaces in .NET, and exposing those to
COM, then creating classes in .net that implement those public interfaces.
The ClassInterface(AutoDual) attribute gets you quick results for little
effort, but it gets sticky if you have to recompile and re-version your
assembly. By explicitly and manually creating interfaces (and assigning
GUIDs), you can properly maintain the assembly and reduce the impact on the
VB6 clients.

I was thinking about it, but the object hierarchy in the .NET assembly
is very large and complicated. So the effort to wrap it would be a
large undertaking. I am actually trying to use the .NET wrapper for
Scheduled Tasks that's available at
http://www.codeproject.com/csharp/TSNewLib.asp

It is actually kind of ironic: the .NET library wraps the COM interfaces
that are difficult to access from VB6 (COM). Then I use a COM tool to
access a .NET wrapper for a COM tool.

 

[Tom Shelton]

I was thinking about it, but the object hierarchy in the .NET assembly
is very large and complicated. So the effort to wrap it would be a
large undertaking. I am actually trying to use the .NET wrapper for
Scheduled Tasks that's available at
http://www.codeproject.com/csharp/TSNewLib.asp

It is actually kind of ironic: the .NET library wraps the COM interfaces
that are difficult to access from VB6 (COM). Then I use a COM tool to
access a .NET wrapper for a COM tool.

Frank,

If all you want is a VB6 Task Scheduler library you can have mine...
Here is the code and the binary:

http://www.mtogden.com/~tom/files/SchedulingAgentVB6.zip
http://www.mtogden.com/~tom/files/SchedulingAgentSource.zip

This includes the project for the dll as well as the IDL source code for
the type library. Feel free to use and modify the code as you see fit.

--
Tom Shelton [MVP]
Powered By Gentoo Linux 1.4
"You're very sure of your facts, " he said at last, "I
couldn't trust the thinking of a man who takes the Universe
- if there is one - for granted. "