views:

387

answers:

2

.NET has a thing called remoting where you can pass objects around between separate appdomains or even physical machines. I don't fully understand how the magic is done, hence this question.

In remoting there are two base ways of passing objects around - either they can be serialized (converted to a bunch of bytes and the rebuilt at the other end) or they can inherit from MarshalByRefObject, in which case .NET makes some transparent proxies and all method calls are forwarded back to the original instance.

This is pretty cool and works like magic. And I don't like magic in programming. Looking at the MarshalByRefObject with the Reflector I don't see anything that would set it apart from any other typical object. Not even a weird internal attribute or anything. So how is the whole transparent proxy thing organized? Can I make such a mechanism myself? Can I make an alternate MyMarshalByRefObject which would not inherit from MarshalByRefObject but would still act the same? Or is MarshalByRefObject receiving some special treatment by the .NET engine itself and the whole remoting feat is non-duplicatable by mere mortals?

+2  A: 

I believe MarshalByRefObject isn't all that special. I believe that its whole reason for existence lies with its lifetime management and how it's garbage-collected on the server. There are some good comments on what this is about in the LifetimeServices class documentation.

AFAIK, the real magic of remoting is done by the remoting infrastructure yourself when you set up the hosts. MarshalByRefObject isn't doing any of the real work of marshalling stuff across AppDomains.

And I agree with M.A. Hanin, if you're starting something new, start with WCF. Remoting is a dead-end technology.

Dave Markle
In my case I only need to communicate across AppDomain boundaries (and that only because I need to unload a managed .DLL). This makes Remoting appealing because it's so simple to use.
Vilx-
OK, anyway, if MarshalByRefObject isn't key to the whole process, what is? What exactly creates the mystical proxies etc?
Vilx-
Take a look at RemotingConfiguration.RegisterWellKnownServiceType(). I had to look it up because I forgot all about Remoting because I switched to WCF 2 years ago. WCF can do everything you want. You'll find more resources for it too. I feel like the old Chinese man from "Gremlins" who warns the kid about his decision, but the kid goes ahead and feeds the thing anyway...
Dave Markle
Vilx-
I don't believe it is possible to *solely* use WCF to control code within a second appdomain. The first step is to create an instance of a type in the second domain and unwrap its proxy in the current. From that point, you have a bridge over which you can send commands into the second domain. How would you construct that bridge just by using WCF? How do you create your service endpoint? Never seen an example of how to do that...
Will
Also, +1 this. Lifetime management is very important with proxies (as anybody who has had an object collected from underneath their proxy knows). MBRO contains code relating to this.
Will
+1  A: 

The magic seems to be in a special TransparentProxy class - the .NET Runtime handles it in a special way.

I think that MarshalByRefObject may contain some additional internal information which can be helpful for this mechanism, but I haven't looked much into that.

akavel