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

Question

我是WCF服务的开发人员.我的测试客户工作得很好.但是当谈到真正的客户端(使用相同的客户端代理)时,它就失败了.相同的WCF服务与netTcpBinding一起使用,只有netNamedPipeBinding才会出现此错误,即使使用ConcurrencyMode = ConcurrencyMode.Single也是如此.

这是例外

在net.pipe:// localhost/MyService上没有可以接受该消息的端点.这通常是由错误的地址或SOAP操作引起的.有关更多详细信息,请参阅InnerException(如果存在).

服务器堆栈跟踪:at

系统.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey(EndpointAddress地址,Uri via)在System.ServiceModel.Channels.CommunicationPool`2.TakeConnection(EndpointAddress地址,Uri via)上的System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName(Uri uri) ,Time.San超时,TKey和密钥)在System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan超时)的System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan超时),System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan超时)at at在System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan超时,CallOnceManager级联)的System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan超时)的System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan超时)
System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)at System.ServiceModel.Channels.ServiceChannel.Call(String action,Boolean oneway,ProxyOperationRuntime operation,Object [] ins,Object [] outs,TimeSpan timeout)at System. System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)中的ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall,ProxyOperationRuntime操作)

在[0]处重新抛出异常:在System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg,IMessage retMsg)处于System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&msgData,Int32 type)at at

内在例外

PipeException:"在本地计算机上找不到管道端点'net.pipe:// localhost/MyService'."

Answer 1

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

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

在Vista之前的Windows平台上,WCF客户端不太可能缺乏打开共享内存的安全权限,从中读取管道名称GUID,然后成功连接到服务的管道.但是在Vista和后来的平台上,有一些新的安全机制使这成为一种更常见的故障情况.

Vista为命名内核对象引入了不同命名空间的概念:有一个全局(机器范围)命名空间,以及每个登录会话的私有命名空间.在查找通告管道名称的共享内存部分时,NetNamedPipeBinding客户端代码将尝试两个名称空间.如果服务器使用全局名称创建了共享内存,或者服务和客户端在同一个登录会话中运行,则客户端将找到它要查找的内容.但是,如果服务无法在全局命名空间中创建对象(它总是首先尝试执行此操作),那么它将回退到创建私有会话命名空间,然后只有在同一会话中运行的客户端才能看到它.创建全局命名空间内核对象需要Vista和更高版本平台的特殊权限,这些平台通常只有Windows服务进程和运行"以管理员身份"运行的应用程序才具有.常见的缺陷是尝试在Windows服务中创建客户端,尝试连接到在交互式用户会话中运行的应用程序中托管的WCF NetNamedPipe服务.

如果客户端代码在较低完整性上下文(例如浏览器插件)中运行,则Vista强制完整性机制还可以阻止假定客户端连接到WCF NetNamedPipeBinding服务,而不是托管服务的代码.

我会想象问题中报告的症状,测试客户端工作但真正的客户端不工作,几乎可以肯定是由于真实客户端的安全上下文与服务主机的安全上下文不一致,原因之一是其中一个原因.

Answer 2

如果搜索此错误并遇到此问题，则可以解决此根本问题的另一种可能性-如果遇到错误，即无法net.pipe在URL中找到地址（即http://localhost:1234/MyService/etc/），请确保启动了Net.Pipe Listener Adapter Windows Service 。（我还启动了Net.Tcp侦听器适配器）

在某些情况下，该服务似乎未启用或启动，尤其是当部署到可能没有安装大量主动使用这些服务的开发工具的远程服务器时。启动服务解决了该问题。