Using WCF to execute code & return objects in another CLR address space

Question

After some reading, i've gather .NET Remoting is a deprecated API which has been replaced by WCF.

I'm writing an automation framework, and would like to reference a DLL with types/methods either locally, or on some remote machine, and execute them without respect to where they are executing.

I thought Remoting is the way to go, since i guess all functionality is performed on a proxy object, making it irrelevant if it is a local object or remote.

How can WCF perform this kind of action (if at all) or .NET Remoting is the way to go ?

Or perhaps some other option i haven't thought of?

Answer 1

There is no magic way to call a method completely transparent without regards to which machine to run it on, as far as I know, including .NET Remoting. However, WCF makes extensive use of proxies, either generated automatically from WSDL documents or by directly referencing the types/interfaces from a shared dll.

Thus, you could create a shared dll containing some methods, add some WCF plumbing (i.e. creating a Service interface out of the methods/types you want to expose) and then decide whether to use them directly/locally in your project, or access them via a proxy. This makes it fairly easy to invoke methods remotely. Note however that you cannot create fully-fledged classes that expose state and functionality remotely, the memory holding the actual objects are not shared remotely, it is, after all, just a 'trick'.

Depending on your setup, you may:

• Use Named Pipes for intra-machine communication (fastest)
• Use TCP for Intranet communication (also pretty fast)
• Use HTTP/HTTPS for Internet communication (slowest)

Although it is easy to invoke remote methods, including sending/returning complex data structures, WCF internally creates a full communication stack, possibly consisting of lots of logic, including for example security, transaction and reliability. This means that remote communication comes with a cost, both stressing the CPU and the network.

A primer to WCF can be found here.

If you want more performance than possible with the built in communication options, you may want to consider using something like Google Protocol Buffers to both slim down the amount of data being transferred and to lower the CPU load.

For C# there are two implementations of Protocol Buffers that I know of, Protobuf CSharp by Jon Skeet and Protobuf-net by Marc Gravell.

A final note just to be clear; no, WCF does not give you a way to fully abstract away the location of types/methods.

Answer 2

.NET Remoting is indeed pretty much deprecated.

WCF has proxy objects just like .NET remoting...whereas in .NET remoting the proxy objects are MarshalByRef objects, in WCF the proxy objects are interfaces or classes attributed with the ServiceContract attribute.

There is no real magic in .NET remoting...it just seems more like magic because a lot less of the plumbing is exposed and pluggible. Even in WCF, at the root of all the infrastructure, the framework creates a RealProxy...the same type used by .NET Remoting.

http://msdn.microsoft.com/en-us/library/system.runtime.remoting.proxies.realproxy.aspx.

At the end of the day, pretty much anything you would previously have used .NET Remoting for can be done with WCF. The only thing I know of that truly functions intrinsically differently is the notions of asynchronous callbacks (which, IMHO didn't work so well in .NET Remoting anyway).