使用WCF执行代码&返回另一个 CLR 地址空间中的对象
经过一番阅读后，我发现 .NET Remoting 是一个已弃用的 API，已被 WCF 取代。
我正在编写一个自动化框架，并且希望在本地或某些远程计算机上引用带有类型/方法的 DLL，并执行它们，而不管它们在哪里执行。
我认为远程处理是可行的方法，因为我猜所有功能都是在代理对象上执行的，因此无论它是本地对象还是远程对象都无关紧要。
WCF 如何执行这种操作（如果有的话）或者 .NET Remoting 是可行的方法？
或者也许是我没有想到的其他选择？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
据我所知，没有什么神奇的方法可以完全透明地调用一个方法，而不管它在哪台机器上运行，包括.NET Remoting。
然而，WCF 广泛使用代理，或者从 WSDL 文档自动生成，或者通过直接引用共享 dll 中的类型/接口。
因此，您可以创建一个包含一些方法的共享 dll，添加一些 WCF 管道（即从您想要公开的方法/类型中创建一个服务接口），然后决定是否在项目中直接/本地使用它们，或者访问它们通过代理。这使得远程调用方法变得相当容易。但请注意，您无法创建远程公开状态和功能的成熟类，保存实际对象的内存不会远程共享，毕竟，这只是一个“技巧”。
根据您的设置，您可以：
虽然很容易调用远程方法，包括发送/返回复杂的数据结构，但 WCF 内部创建了一个完整的通信堆栈，可能包含大量逻辑，包括安全性、事务和可靠性等。这意味着远程通信是有代价的，会给 CPU 和网络带来压力。
可以在此处找到 WCF 入门知识。
如果您希望通过内置通信选项获得更高的性能，您可能需要考虑使用 Google 协议缓冲区可减少传输的数据量并降低 CPU 负载。
对于 C#，据我所知，Protobuf CSharp 有两种实现：Protobuf CSharp作者：Jon Skeet 和 Protobuf-net 作者：Marc Gravell。
最后一点是为了明确起见；不，WCF 不为您提供一种完全抽象类型/方法位置的方法。
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:
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 确实已经被弃用了。
WCF 具有代理对象，就像 .NET 远程处理一样...而在 .NET 远程处理中，代理对象是 MarshalByRef 对象，而在 WCF 中，代理对象是具有 ServiceContract 属性的接口或类。
.NET 远程处理中并没有真正的魔法……它只是看起来更像魔法，因为暴露和可插拔的管道少了很多。即使在 WCF 中，在所有基础设施的根部，框架也会创建一个 RealProxy...与 .NET Remoting 使用的类型相同。
http://msdn.microsoft.com/en -us/library/system.runtime.remoting.proxies.realproxy.aspx。
归根结底，您以前使用 .NET Remoting 完成的几乎任何事情都可以通过 WCF 完成。我所知道的唯一真正在本质上不同的功能是异步回调的概念（恕我直言，无论如何，异步回调在 .NET Remoting 中工作得不太好）。
.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 使用 SOA 方法：
您可以定义 ServiceContracts 和 DataContracts，
但是，您不能同时公开具有状态和功能的对象。
ServiceContract 是一个生命周期与 DataContract 的生命周期无关的对象，
它可以是单例，也可以在每次调用时创建。
数据契约只是哑数据，在服务器和客户端之间来回发送。
只有它们的 DataMember 暴露给客户端。
ServiceContracts 将所有方法作为可以接收和返回 DataContracts 的 OperationContracts 向客户端公开。
WCF 在客户端为 ServiceContract 和 DataContracts 创建代理，因此当您编写服务或使用它。
无论您采用哪种方法，都必须考虑代码是在同一应用程序中运行还是通过另一个应用程序（本地或远程）运行 - 线程安全、同步、事件、超时等。
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.