远程处理或WCF新发展（之间在同一台机器上的两个.NET应用程序）使用接口？ [英] Remoting or WCF for new development (between two .NET apps on the same machine) using interfaces?
问题描述
我们希望在同一台机器上运行两个应用程序。NET相互通信。我们希望三个项目。包含接口库。 服务器的应用程序，实现了使用接口的服务器通信的接口和客户应用程序。我们不希望客户端引用服务器。
我们有一个测试程序，这是否与远程处理，但最近发现，远程被替换使用WCF。由于这是新的发展，我们觉得我们应该使用WCF，但我们没有设法使其与WCF工作，并想知道是否有可能？
We want to have two .NET apps running on the same machine communicate with each other. We want three projects. A library containing interfaces. A "server" app that implements the interfaces and "client" app that communicates with the server using the interfaces. We do not want the client to reference the server.
We have a test app that does this with remoting but recently discovered that remoting is being replaced with WCF. Since this is new development we feel we should use WCF but we haven't managed to make it work with WCF and were wondering if it is possible?
对不起，我缺乏细节之上，但我没有在当时获得的任何代码。我与另外两个人在这个项目上的工作，并没有在他们的IPC东西仔细地看了看。我知道，他们都认为，目前的WCF不能做他们想要做什么，我希望能够向他们展示，它可以。
Sorry for my lack of detail above but I didn't have access to any code at the time. I am working with two other people on this project and haven't looked closely at their IPC stuff. I know that they are currently of the opinion that WCF cannot do what they want it to do and I am hoping to be able to show them that it can.
我已经开始寻找我的同事试图在这一点，将继续更新这个帖子，我理解这一点。
I've started looking at my coworkers attempts at this and will continue to update this post as I understand it.
下面是对远程的测试代码的简化版本。他们希望能够做到这一点使用WCF但到目前为止一直未能得到它的工作。
Below is a simplified version of their test code for remoting. They want to be able to do this using WCF but so far have been unable to get it to work.
- Lib\的 IMessage.cs
- IService.cs
- Service.cs
- ServiceMessage.cs
- ServiceApp\的ServiceProgram.cs
- ClientProgram。 CS
- Lib\ IMessage.cs
- Lib\ IService.cs
- ServiceApp\ Service.cs
- ServiceApp\ ServiceMessage.cs
- ServiceApp\ ServiceProgram.cs
- ClientApp\ ClientProgram.cs
无论是ServiceApp和ClientApp组件引用库组件。他们不相互引用。
Both the ServiceApp and ClientApp assemblies reference the Lib assembly. They do not reference each other.
当我能够更好地解释他们试图复制在WCF这种行为，我会再次进行编辑。在这一点上我真正知道的是，他们正在使用NetNamedPipeBinding并正与客户端应用程序抱怨无法访问该服务组装的麻烦。
I will edit this again when I am better able to explain their attempt to replicate this behavior in WCF. At this point all I really know is that they are using NetNamedPipeBinding and are having trouble with the client app complaining that it cannot access the service assembly.
下面是WCF测试代码的简化版本。
Below is a simplified version of the test code for WCF.
- IMessage.cs
- IService.cs
- ServiceApp\ < A HREF =http://snipt.org/mpom> Service.cs
- ServiceApp\的 ServiceMessage.cs
- ServiceProgram.cs
- ClientProgram.cs
- Lib\ IMessage.cs
- Lib\ IService.cs
- ServiceApp\ Service.cs
- ServiceApp\ ServiceMessage.cs
- ServiceApp\ ServiceProgram.cs
- ClientApp\ ClientProgram.cs
这ClientProgram以下行抛出异常：
The following line from ClientProgram throws an exception:
IMessage msg2 = service.CreateMessage("Hello World");
下面是个例外：
Could not load file or assembly 'ServiceApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
在试图理解史蒂芬的最新评论我GOOGLE IMetadataExchange接口，当然其中有其先打的 MSDN页。这页说：
In trying to understand Steven's latest comment I googled IMetadataExchange which of course had as its first hit the MSDN Page. This page said:
有没有必要实施服务实现的MetadataReference合同。相反，添加的ServiceMetadataBehavior到服务描述。
There is no need to implement the MetadataReference contract in your service implementation. Instead, add the ServiceMetadataBehavior to the service description.
或者，使用配置时，设置端点元素IMetadataExchange接口的合同属性。有关示例，请参见如何：发布元数据服务使用配置文件
Or, when using configuration, set the contract attribute of the endpoint element to IMetadataExchange. For an example, see How to: Publish Metadata for a Service Using a Configuration File.
有关在WCF发布元数据看到的Publishing元。
For details on publishing metadata in WCF see Publishing Metadata.
由于，对于这个例子中，我没有使用配置文件，而是我选择去了发布元数据链接。从那里，我去如何发布元数据服务使用代码链接，有一个很好的例子，我用修改我的服务的应用程序代码。所添加的代码是行15-20。
Because, for this example, I am not using configuration files but instead I choose to go to the Publishing Metadata link. From there I went to the How to: Publish Metadata for a Service Using Code link which had a nice example that I used to modify my service app code. The added code is on lines 15-20.
我可以一点点工作，后添加服务引用。该服务已在运行，但如果你通过运行Visual Studio中的服务，那么你就不必添加服务引用的选项。另外，我还是不明白发现服务在解决方案选项如何工作。最后，我能够通过斌/ debug文件夹打开手动运行该服务，然后进入我加入到我的服务应用程序的URL添加引用。如果这是正确的方式，颇为尴尬。
I was able to add the Service Reference after a little work. The service has to be running but if you run the service through Visual Studio then you don’t have the option to add the service reference. Also, I still don't understand how the "Discover Services in Solution" option is supposed to work. In the end I was able to add the reference by opening by bin/debug folder to manually run the service and then entering the URL I added to my service app. If this is the correct way it rather awkward.
After all of that the code generated doesn’t make any since to me. First off it recreates my IService interface but turns all my IMessages into objects and decorates it slightly differently. If their interface is used then not only will it be using a different IService then my service actually implements but the methods in this IService don't even have the same signatures!
把那一边我以为我会改变我的客户，所以我改变了我的客户端代码使用的对象来自新生成的对象。
Putting that aside I assumed I would have to change my client to use the objects from the newly generated object so I changed my client code.
现在，当我尝试运行它，我得到第4行出现以下错误：
Now when I attempt to run it I get the following error on line 4:
The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:msg. The InnerException message was 'XML 'Element' 'http://tempuri.org/:msg' does not contain expected attribute 'http://schemas.microsoft.com/2003/10/Serialization/:Type'. The deserializer has no knowledge of which type to deserialize. Check that the type being serialized has the same contract as the type being deserialized.'. Please see InnerException for more details.
有一天离开赏金，因为我加入赏金没有答案。 ？有什么我可以澄清之前赏金的时间到了。
One day left for the bounty and no answers since I added the bounty. Is there anything I can clarify before the bounty time is up?
在我们和远程去，因为它不看，如果我们想要做什么是可能的WCF结束。史蒂芬Sudit得到的，尽管事实上，这是所有我之前所提供的赏金他的所有帮助赏金。
In the end we went with remoting because it doesn't look as if what we want to do is possible with WCF. Steven Sudit gets the bounty for all his help despite the fact that it was all before I offered the bounty.
推荐答案
远程有一些使用的情况下，如一个单一的过程中应用程序域之间的通信。说了这么多，是的，WCF是要走的路。从一些你所说的事情，不过，我不知道，如果你明白这是如何工作的。
Remoting has some use cases, such as communication among appdomains within a single process. Having said that, yes, WCF is the way to go. From some of the things you've said, though, I'm not sure if you understand how this is supposed to work.
通常的方式来做事的WCF是建立全部由数据传输对象（所有属性，没有代码）和接口共享程序集。双方都引用这个组件，但是客户端使用服务器的服务引用。这是否帮助？
The usual way to do things in WCF is to create a shared assembly consisting entirely of data transfer objects (all properties, no code) and interfaces. Both sides reference this assembly, but the client uses a service reference of the server. Does that help?
这篇关于远程处理或WCF新发展（之间在同一台机器上的两个.NET应用程序）使用接口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
