Using WCF to execute code & return objects in another CLR address space_问答_开发者

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?

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.

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

WCF uses a SOA approach:

You can define ServiceContracts and DataContracts,
however, you can not expose objects with both state and functionality.

The ServiceContract is an object who's lifetime is not connected to that of the DataContracts, it can be either a singleton, or created at each call.

The DataContracts are just dumb data, sent back a forth between server and client.
Only their DataMembers are exposed to the client.

The ServiceContracts expose all the methods to your client as OperationContracts that can receive and return DataContracts.

WCF creates proxies for ServiceContract and DataContracts on the client side, so you don't need to think about sending/receiving packages and such when you write a service or consume it.

Whatever approach you take, there are considerations you must think of regarding whether the code is ran in the same application or via another application (locally or remotely) - thread safety, synchronization, events, time outs, and more.