How to overcome the limitation: Cannot pass 'argument' as ref or out, because ' argument ' is a mars

  • Thread starter Thread starter Mountain Bikn' Guy
  • Start date Start date
M

Mountain Bikn' Guy

It is known that one cannot pass arguments as ref or out in a
marshal-by-reference class. My problem is that I have a C DLL (and C#
wrapper) that I need to isolate in an AppDomain and then I need to interact
with many objects in that DLL and wrapper by reference. (So the classes
inherit from MBRO.) While my app is running, I need to obtain info from
objects in the 2nd app domain frequently/speedily and I need update the GUI;
and I need to pass user actions back to the DLL. I also need to handle
events across the AppDomain boundary. All this sounds fairly standard, I
guess (I'm new to remoting.)

However, the C# wrapper has a lot of methods that use 'out' parameters, and
I can't change this (might as well rewrite the whole app from scratch). So,
my question is, How can I isolate this set of objects in an AppDomain
without throwing all that code away? The methods with ref and out parameters
could be wholly 'bounded' or contained within the new AppDomain. In other
words, these methods are not needed in regard to communicating across the
AppDomain boundary, but are only needed for objects within the new AppDomain
to interact with each other. Any suggestions on how to do this?

On a different but related point, I read in a post from 2001 the following:
" Fields of App-Domain-bound objects must be accessed through accessors.
so for any objects derived from MarshalByRefObject (as is your TreeNode)
you must provide put/get methods (for your color member)."

If I understand that correctly, it means that implementing Properties in
place of certain methods the C# wrapper currently uses for returning values
would help. But that doesn't solve my main ref/out param issue, but it is
interesting. Anyone care to point me to more info on either/both of these
topics?

Dave
 
Hum, complex topic. What you should do IMO, if the objects you need are
created and consumed in your second AppDomain, is to create a proxy object
that you create from your first AppDomain in your second AppDomain using
CreateInstanceAndUnwrap. If this object inherit from MBR, you can then use
it to call methods that will in fact execute in the second application
domain, and you can, in these methods create your objects or get back the
objects from the out and ref parameters of your C dll. It's then just a
matter of getting the value you want back, and put them in a MBV back to
your first AppDomain to prevent any more marshalling.

This is the only way I could figure to get good encapsulation and prevent a
few nifty remoting tricks such as viral dll loading across appdomains :)

--
Sebastien Lambla
http://thetechnologist.is-a-geek.com/blog/


Mountain Bikn' Guy said:
It is known that one cannot pass arguments as ref or out in a
marshal-by-reference class. My problem is that I have a C DLL (and C#
wrapper) that I need to isolate in an AppDomain and then I need to interact
with many objects in that DLL and wrapper by reference. (So the classes
inherit from MBRO.) While my app is running, I need to obtain info from
objects in the 2nd app domain frequently/speedily and I need update the GUI;
and I need to pass user actions back to the DLL. I also need to handle
events across the AppDomain boundary. All this sounds fairly standard, I
guess (I'm new to remoting.)

However, the C# wrapper has a lot of methods that use 'out' parameters, and
I can't change this (might as well rewrite the whole app from scratch). So,
my question is, How can I isolate this set of objects in an AppDomain
without throwing all that code away? The methods with ref and out parameters
could be wholly 'bounded' or contained within the new AppDomain. In other
words, these methods are not needed in regard to communicating across the
AppDomain boundary, but are only needed for objects within the new AppDomain
to interact with each other. Any suggestions on how to do this?
Click to expand...
 
Thank you for your reply. This is a very helpful suggestion and I'll
remember it when I need to use it. For now, I have decided not to use a 2nd
AppDomain.

Sebastien Lambla said:
Hum, complex topic. What you should do IMO, if the objects you need are
created and consumed in your second AppDomain, is to create a proxy object
that you create from your first AppDomain in your second AppDomain using
CreateInstanceAndUnwrap. If this object inherit from MBR, you can then use
it to call methods that will in fact execute in the second application
domain, and you can, in these methods create your objects or get back the
objects from the out and ref parameters of your C dll. It's then just a
matter of getting the value you want back, and put them in a MBV back to
your first AppDomain to prevent any more marshalling.

This is the only way I could figure to get good encapsulation and prevent a
few nifty remoting tricks such as viral dll loading across appdomains :)
Click to expand...
 
Back
Top