Is MarshalByRefObject special?

.NET has a thing called deletion, where you can transfer objects between separate applications or even physical machines. I do not quite understand how this is done, therefore this question.

There are two main ways to transfer objects in deletion: either they can be serialized (converted to a bunch of bytes and rebuilt on the other end), or they can inherit from MarshalByRefObject , in which case .NET makes some transparent proxies, and all method calls are sent back to the original instance.

It's pretty cool and works like magic. And I do not like magic in programming. Looking at a MarshalByRefObject with a Reflector, I don’t see anything to distinguish it from any other typical object. Not even a weird internal attribute or something else. So, how is the whole transparent proxy organized? Can I create such a mechanism myself? Can I make an alternative MyMarshalByRefObject , which does not inherit from MarshalByRefObject , but still acts the same? Or does MarshalByRefObject receive special treatment from the .NET engine itself, and the whole remote mind is not duplicated by mere mortals?

+47
clr remoting
- Apr 27 '10 at 11:27
source share
2 answers

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

I think that MarshalByRefObject may contain some additional internal information that may be useful for this mechanism, but I didn’t think much about it.

+17
Jun 02 '10 at 11:32
source share

I find MarshalByRefObject not so special. I believe that his whole reason for his existence lies in his life cycle management and how he collects garbage on the server. There are some good comments regarding LifetimeServices .

AFAIK, the real magic of distance is carried out by the most remote infrastructure when setting up hosts. MarshalByRefObject does no real job of sorting files through AppDomains.

+4
Apr 27 '10 at 11:46 a.m.
source share



All Articles