Use .net remoting to call a local "remote"?

Question

I have a large app which uses COM via .net remoting to call from the web tier to the middle tier. It's quite slow to startup and to run when in this mode. Both sides of the COM boundary are our code.

I'd like to be able to (optionally) run it in a single process. Quite a bit of the behaviour relies on calls to ServicedComponents having all their arguments serialized, and that changes made to the objects inside the components don't leak out unless the argument is a 'ref' argument.

My current plan to force this two-process app into a single process without needing to change too much code is by using a fake middle tier boundary with custom .net remoting.

If I change all the:

class BigComponent : ServicedComponent {
   ...
}

into

[FakeComponent]
class BigComponent : ContextBoundObject {
   ...
}

Then I can write a custom ContextAttribute to fake the process boundary and make the arguments serialize themselves:

i.e.

[AttributeUsage(AttributeTargets.Class)]
public class FakeComponentAttribute :
  ContextAttribute,
  IContributeServerContextSink
{
   ... lots of stuff here
}

As per http://msdn.microsoft.com/en-us/magazine/cc164165.aspx

Now this works fine, so far, and I can intercept all calls to methods on these classes. However, I can only view the IMethodCallMessage.Args in the IMessageSink.ProcessMessage call -- I don't seem to be able to replace them with objects of my choice.

Any time I change entries in the IMethodCallMessage.Args array, my changes are ignored. From what I can tell in Reflector, this interface is a wrapper around a native object in the runtime itself, and I can't write to this object, just read it.

How can I modify the arguments to method calls in .net remoting?

Do I need to implement my own Channel? Is there a "local" channel tutorial out there I can crib from?

My aim is to have these Components act like remote objects (in that all their args get serialized on the way in to the method, and that their return value is serialized on the way out), but have the remote endpoint be inside the same process.

Did you know that Remoting has been deprecated in favor of WCF? That would probably speed things up quite a bit. — John Saunders, Sep 09 '11 at 19:17
@John Saunders: Technically, [remoting is not depricated](http://msdn.microsoft.com/en-us/library/72x4h507(v=VS.100).aspx), it's a legacy technology that is not recommended for new development. Additionally, saying WCF would "probably speed things up" is an over-generalization, as [there are cases where WCF is slower than remoting](http://stackoverflow.com/questions/1295353/why-am-i-seeing-slower-performance-here-from-wcf-than-remoting) — casperOne, Sep 09 '11 at 20:16
I meant that WCF _could_ speed things up if, for instance, `net.tcp` or `net.pipes` is used with binary. Also, the link you provided is pretty much the definition of "deprecated" - "don't use it for anything new, switch old code when possible". — John Saunders, Sep 09 '11 at 20:23
I know that Remoting has been deprecated. However, my question relates to modifying a large legacy app which uses COM+, and trying to make a minimal change to it in a localised fashion. Ripping out all the hundreds of COM+ components and replacing them with WCF isn't even remotely on the cards here. — Rich, Sep 19 '11 at 15:43

score 0 · Accepted Answer · answered Nov 01 '12 at 12:00

I have not found a way to edit the argument array as it passes through the IMessageSink.

In the end, I had to make the argument object classes aware of this issue, and implement a new interface IFakeRemotingAware. This allowed the complex object arguments which exhibit the pass-by-val behaviour due to serialization/deserialization when using remoting to simulate that behaviour when using fake remoting.

The interface has two methods: EnteringFakeRemote which causes the object to cache a local copy of its state, and LeavingFakeRemote which causes the object to restore its state from the cache.

Use .net remoting to call a local "remote"?

1 Answers1