Is MarshalByRefObject special?

Question

.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?

Belayneh

If .NET Remoting treats all classes which inherit from MarshalByRefObject in a special manner, does that qualify for "MarshalByRefObject is special"? Use the Reflector on .NET Remoting and find the magic. BTW, .NET Remoting is obsolete, along with MarshalByRefObject. It can be used, of course, but WCF is the currently predominant "remoting architecture" in .NET. – Shirberg

WCF still supports MarshalByRefObject – Jeroboam

The magic is in the jitter, it treats MBRO classes special. It no longer directly accesses fields in a class but generates code to use a CLR helper method instead. Which is aware that the object is remoted so knows when to generate a proxy call. – Bailes

Answer 1

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

• If you want to use it, see an article about RealProxy
• If you want to read more about the "magic", see an article on TransparentProxy implementation.
• For a basic overview, try the MSDN article "Remoting: A Technical Overview".

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.

Musclebound

Article about RealProxy is broken (or at least private) – Refinement

Thanks for info, looks so for me too :-( Unfortunately, I can't find it on web.archive.org either. Maybe trying to contact the author @thomas-danecker personally could help somehow – Musclebound

Just to be clear, MarshalByRefObject and classes derived from is ARE special, in much the same way that ValueTypes are special: the JIT changes some of its code generation when dealing with a MarshalByRefObject, and disables certain optimizations. When you have a reference to any object 'x' that derives from MarshalByRefObject, the JIT must always consider the possibility that x is a TransparentProxy to a remote object. For example, inlining might be disabled, or guarded with a check to test whether 'x' is local or remote first. – Kartis

Interestingly, if a class X is derived from MarhalByRefObject, you can even create "fake" instances of X in which a "real" X does not exist at all. This makes MarshalByRefObjects a lot like interfaces, because it is possible (although not easy) to replace an X object with something that is not of type X, but implements X's "interface". This article on the subject is pretty cool: ikriv.com/en/prog/info/dotnet/RhinoMocks.html – Kartis

Damn this MarshalByRefObjects, cuz of error handling problems. Is this class obsolete? – Preconceive

Answer 2

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.

Apperception

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. – Belayneh

OK, anyway, if MarshalByRefObject isn't key to the whole process, what is? What exactly creates the mystical proxies etc? – Belayneh

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... – Apperception

If I hadn't written a bunch of code with it already, I'd consider it. But, honestly, for what I'm using of it, I can't imagine it being any simpler & easier to write. – Belayneh

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... – Xiphoid

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. – Xiphoid