First of all, thanks to everyone for the many very educational responses. I
had not seen much discussion in articles or books about this situation, so I
really appreciate the advice.

Second, it is true that all the interfaces in question inherit from
IDispatch in the IDL. So, ISearch "is-a" IDispatch.

I was curious though why certain libraries on my system, when viewed in OLE
View, show a mixture of IDispatch and IDispatch-derived declarations like
within the Windows Media Player library:

[id(0x0000001b), propget, helpstring("Returns the player application handler")]
        HRESULT playerApplication([out, retval] IWMPPlayerApplication**
ppIWMPPlayerApplication);

When generating the RCW from this, the .NET declaration is of type
IWMPPlayerApplication instead of object.

Thanks also for the suggestion about the flyweight. I thought about
something along these lines too. We are in the very early stages of this
project, but I'm trying to think forward as to what the best way to re-use
the existing interface contracts will be in a world without COM and
asp/vbscript. Obviously, asp.net should ideally not have a dependency on
implementation details such as IDispatch if that requirement is to go away
in time.

It's not clear yet how much interop will be involved in the intial stages,
but if it looks like there will be a lot, one idea I had was to reuse as
much of the interface declarations as possible from the RCWs, and in the
case where IDispatch currently is mapped to object, just manually create a
"wrapper wrapper" that hides the QI cast within a property get{} statement.
That way, the interface contract that the ASP.net consumer code depends on
will remain the same moving forward when the underlying COM is replaced with C#.

Of course, this would require facading the whole entire auto-genned rcw with
getter/setters for all of the other properties as well, so that was why I
was curious about what the implications would be of forcing the rcw to
perform the QI by manipulating the idl.

If however there is not a whole lot of interop, then it will probably just
be easier to manually cast and rework it later when the time comes. Will
just have to bite the bullet on the seeming inelegance of it.

Thanks again everyone,
Josh

===================================
This list is hosted by DevelopMentorĀ®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to