Vent on COM Interop (Consuming .NET in VB6)

[tcarvin]

If you are not in the mood for a rant, then leave now...

I figure most VB.NET programmers have a VB6 background, so I hope you all
don't mind the semi-VB.NET related Interop posting.

Like most of you, we have a large base of VB6 that must be maintained (and
even enhanced), while we are trying to do some new development in VB.NET.

I recently had to make a .NET library I wrote available to my VB6 application.

Considering how easy going from COM to .NET was, going in reverse was a big
pain in the butt.

After reading several articles online (and various section of MSDN help)
I got the gist of the process, but I was most annoyed at the implicit class
interface versus the explicit interface approach. There are tutorial that
explain just slapping a few attributes on the public classes and voila, your
class interface is created. Then two paragraphs later you read a "this is
strongly discouraged in production systems due to client versioning issues".
Don't waste my time explaining the wrong way to do something, I'm busy enough
already.

OK, so I understand that you must explicitly create an Interface to expose
to COM (decorated with a dozen or so attributes after you include the DispIds
on the methods) ... for each and every public class. Then you have to
implement those interfaces through out your assembly (including adding more
attributes to your public classes to hide them from the TypeLibs now that
you are defining them yourself).

But then I hit issues with casting caused by the interfaces versus classes.
I can't just throw an "Implements IMyComInterface.MethodX" onto my MethodX,
because it uses an arguement MyArgForMethodX. But to COM that is an
IMyArgForMethodX instead so my signitures don't match. So now I have to
define the whole bank of interface methods (which mirror my public methods)
and then delegate to my real methods.

You can't tell me that this all could not have been done behind the scenes
when I checked "Register for COM Interop". Or perhaps a wizard or something.
This seems like such a manual process.

And finally, apparently I cannot cast from an array of IMyArgForMethodX to
and array of MyArgForMethodX, so my methods that took arrays now have to have
to explicitly copy from the source array to a temp array and then forward to
my public methods.

Phew. OK, venting done. Well anyway, if anyone has any problems doing
COM Interop you can give me a shout. I think I hit every problem possible
(more than I listed) on my way to getting it to work (which it now does).

Tom

[Robin Tucker]

You aren't kidding. Interop is a gigantic pain in the behind. According to
the latest edition, it is approximately 1,597 pages of pain in the behind
(.NET and COM The Complete Interoperability Guide).

"tcarvin" <NO***********@lycos.com> wrote in message
news:9f*************************@posting.google.co m...

If you are not in the mood for a rant, then leave now...

I figure most VB.NET programmers have a VB6 background, so I hope you all
don't mind the semi-VB.NET related Interop posting.

Like most of you, we have a large base of VB6 that must be maintained (and
even enhanced), while we are trying to do some new development in VB.NET.

I recently had to make a .NET library I wrote available to my VB6
application.

Considering how easy going from COM to .NET was, going in reverse was a
big
pain in the butt.

After reading several articles online (and various section of MSDN help)
I got the gist of the process, but I was most annoyed at the implicit
class
interface versus the explicit interface approach. There are tutorial that
explain just slapping a few attributes on the public classes and voila,
your
class interface is created. Then two paragraphs later you read a "this is
strongly discouraged in production systems due to client versioning
issues".
Don't waste my time explaining the wrong way to do something, I'm busy
enough
already.

OK, so I understand that you must explicitly create an Interface to expose
to COM (decorated with a dozen or so attributes after you include the
DispIds
on the methods) ... for each and every public class. Then you have to
implement those interfaces through out your assembly (including adding
more
attributes to your public classes to hide them from the TypeLibs now that
you are defining them yourself).

But then I hit issues with casting caused by the interfaces versus
classes.
I can't just throw an "Implements IMyComInterface.MethodX" onto my
MethodX,
because it uses an arguement MyArgForMethodX. But to COM that is an
IMyArgForMethodX instead so my signitures don't match. So now I have to
define the whole bank of interface methods (which mirror my public
methods)
and then delegate to my real methods.

You can't tell me that this all could not have been done behind the scenes
when I checked "Register for COM Interop". Or perhaps a wizard or
something.
This seems like such a manual process.

And finally, apparently I cannot cast from an array of IMyArgForMethodX to
and array of MyArgForMethodX, so my methods that took arrays now have to
have
to explicitly copy from the source array to a temp array and then forward
to
my public methods.

Phew. OK, venting done. Well anyway, if anyone has any problems doing
COM Interop you can give me a shout. I think I hit every problem possible
(more than I listed) on my way to getting it to work (which it now does).

Tom