How to overcome the limitation: Cannot pass 'argument' as ref or out, because ' argument ' is a marshal-by-reference class

[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 MarshalByRefObj ect (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

[Sebastien Lambla]

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
CreateInstanceA ndUnwrap. 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" <[e-mail] > a écrit dans le message de news:
cBRpb.77282$275 .206628@attbi_s 53...

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 MarshalByRefObj ect (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

[Mountain Bikn' Guy]

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" <se************ **@6sens.com> wrote in message
news:u$******** ******@TK2MSFTN GP11.phx.gbl...

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
CreateInstanceA ndUnwrap. 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" <[e-mail] > a écrit dans le message de news:
cBRpb.77282$275 .206628@attbi_s 53...

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 MarshalByRefObj ect (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