使用WCF netNamedPipeBinding时找不到命名管道

Question

我是WCF服务的开发者。我的测试客户处理得很好。但是当涉及到真正的客户端(使用相同的客户端代理)时，它会失败。相同的WCF服务适用于netTcpBinding，此错误仅在netNamedPipeBinding中发生，即使ConcurrencyMode = ConcurrencyMode.Single也是如此。

这是个例外

没有端点侦听net.pir://localhost/MyService可以接受消息。这通常是由不正确的地址或SOAP操作造成的。有关更多细节，请参见InnerException (如果存在)。

服务器堆栈跟踪: at

( System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName(Uri uri)在System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey(EndpointAddress地址，Uri (在System.ServiceModel.Channels.CommunicationPool`2.TakeConnection(EndpointAddress地址)，Uri via，TimeSpan超时，( TKey& key)在System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan超时)在System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan超时)在System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan超时)在System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan超时)在System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan超时)(在System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan超时时，CallOnceManager级联) (在System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan超时值)在System.ServiceModel.Channels.ServiceChannel.Call(String动作，布尔单程，ProxyOperationRuntime操作，Object[] ins，Object[] outs，TimeSpan超时值)在System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall，ProxyOperationRuntime操作)在System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage消息) 异常重新引发: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg，IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData，Int32 type)

内部异常

PipeException：“在本地计算机上找不到管道端点‘net.pir://localhost/MyService’。”

Answer 1

堆栈跟踪显示，当试图从服务URL派生服务所使用的命名管道的实际名称时，客户端WCF通道堆栈失败。服务通过在命名共享内存部分中放置一个小结构来发布管道名称(它是一个GUID，每次服务重新启动时都会更改)，其中包含GUID作为其字段之一。用于共享内存部分的名称是通过应用一个算法从服务URL派生出来的，该算法被编译到NetNamedPipeBinding的服务器端和客户端WCF代码中。

问题中报告的异常实际上意味着，在将算法应用于服务URL以获得名称后，客户端代码无法打开该名称的共享内存部分的句柄。这可能意味着，正如异常消息所述，没有任何服务侦听用于派生名称的服务URL。但这可能意味着内存部分在那里，服务也在那里，但是客户端代码没有在安全上下文中运行，从而允许它访问共享内存。

在Vista之前的Windows平台上，WCF客户端不太可能缺乏打开共享内存、从其中读取管道名称GUID的安全权限，然后成功地连接到服务的管道。但是在Vista和以后的平台上，有了新的安全机制，使得这成为一个更常见的失败场景。

Vista为命名内核对象引入了不同名称空间的概念:有一个全局(机器范围的)命名空间，每个登录会话都有一个私有名称空间。当查找显示管道名称的共享内存部分时，NetNamedPipeBinding客户端代码将尝试这两个命名空间。如果服务器使用全局名称创建了共享内存，或者如果服务和客户端在同一个登录会话中运行，那么客户机将找到它正在寻找的内容。但是，如果服务不能在全局命名空间中创建对象(它总是尝试首先创建对象)，那么它将返回到创建它--私有会话命名空间，然后只有在同一会话中运行的客户端才能看到它。在Vista和以后的平台中创建全局命名空间内核对象需要一个特殊的特权，通常只有运行"As Administrator“的Windows服务进程和应用程序才具有特权。一个常见的缺陷是尝试在Windows中创建一个客户端，试图连接到在交互式用户会话中运行的应用程序中托管的WCF NetNamedPipe服务。

Vista强制完整性机制还可以防止假定的客户端连接到WCF NetNamedPipeBinding服务，如果客户端代码运行在比承载服务的代码更低的完整性上下文(例如浏览器插件)中。

我可以想象，问题中报告的症状--测试客户端正常工作，但实际客户端不工作--几乎可以肯定是由实际客户端的安全上下文与服务主机的安全上下文不一致造成的，原因之一就是这些原因。

Answer 2

如果搜索此错误并遇到此帖子，则另一种修复此根本问题的可能性--如果您收到一个无法在url (即net.pipe )找到任何http://localhost:1234/MyService/etc/地址的错误，请确保启动了Net.Pipe侦听器适配器服务。(我还启动了Net.Tcp侦听器适配器)

在某些情况下，该服务似乎没有启用或启动，特别是当部署到可能没有安装了许多积极使用这些服务的开发工具的远程服务器时。启动服务解决了问题。

Answer 3

客户端使用的端点必须与WCF服务公开的端点匹配。这意味着指定客户端点的地址/绑定/契约元组必须与WCF服务公开的端点的地址/绑定/契约元组完全匹配。如果您正在使用app.config方法，请确保WCF服务和客户端配置文件中的所有内容都拼写正确。如果要以编程方式添加端点，请确保代码中没有拼写错误。