NET Remoting and MarshalByRefObject is really dead?

8
votes

I'm working on a project requiring inter-AppDomain-intra-process and inter-process-intra-machine communication. Yes... I know... NET Remoting is widely considered a legacy technology but I'm facing with two very special problems and maybe in these scenario WCF is not a full replacement of NET Remoting.

1) inter-AppDomain-intra-process communication

The application I'm working on start and need to search and load one on more addins. I wish to load each addin in a separate AppDomain. I need a way to create the each Addin instance in his AppDomain and call some interface methods of this instance at some point. Here NET Remoting is the only way, right? Moreover if we wish to apply the System.Addins paradigm, apparently based only NET Remoting and not marked as obsolete...

2) inter-process-intra-machine communication

Here I can for sure expose from my application a WCF service and call this service from my client using Named Pipes.

What I really want to do is to expose an object model from my application, so that my application can be automated from some NET client, much like the OLE/COM Automation object model exposed by Excel. Any COM Client can get an object reference to Excel.Application and query open documents, open some new documents and so on.

I think WCF is good to communicate in a platform independent way. But in this case I need only to communicate from Net client to Net application on the same machine. WCF service phylosophy don't allow, I think, to expose a rich object model with objects, collection, field, static member, method overloading... Or I'm wrong?

Please excuse my bad english and my perhaps newbie question.

1
wcfadd-inremoting.net

1 Answers

2
votes

You can read answers to a similar question here: Is .NET Remoting really deprecated?

I can add that I used .NET Remoting recently for relatively simple bi-directional inter-process communication, and all went almost seamlessly, so I can say it is still very usable after all the years of not being actively supported by Microsoft.

As for COM, if you have strong requirements for your product to be accessible by COM-clients, I would suggest to implement COM interfaces explicitly, via COM interop. Also, there is an interesting article about using COM and .NET Remoting together that might be of interest: http://msdn.microsoft.com/en-us/magazine/cc164085.aspx