Obj*_*art 23 .net wcf net.pipe
我们的应用程序使用WCF而不是命名管道来在两个进程之间进行通信(注意:这两个进程都不是Windows服务.)我们的应用程序已经在现场运行了几年而没有发生任何事故.
我们现在收到报告称第三方应用程序(特别是Garmin Express)的存在正在打破我们的行为.我已经在内部安装了Garmin Express并确认了这一行为.特别是"Garmin核心更新服务"在运行时会导致我们的应用程序失败.
当Garmin服务运行时,我们的应用程序的"服务"端启动,并且创建WCF端点没有问题.但是当客户端启动并尝试连接到服务时,它会因EndpointNotFoundException而失败,就好像服务甚至没有运行一样.
此时,我可以从服务控制面板停止Garmin服务,然后成功重新运行客户端,甚至无需重新启动我们自己的服务.如果我再次启动Garmin服务,则进一步尝试启动客户端会失败.所以这至少证明了我们的WCF服务一直在运行,并且Garmin软件以某种方式阻止了我们客户端连接它的能力.
我们使用自己的名称作为端点地址(例如"net.pipe:// localhost/MyPrivateApplication").我已经尝试将此地址更改为其他各种名称,但这对此问题没有影响.
另一个应用程序如何通过运行来破坏我们自己的应用程序使用WCF的能力?
更新:根据请求,这是服务端的代码段.我已经从原始代码中简化了它,试图找出问题所在.到目前为止,我所做的改变并没有对这个问题产生任何影响.
MyService service = new MyService();
ServiceHost host = new ServiceHost(service);
string hostAddress = new Uri("net.pipe://localhost/MyWCFConnection");
host.AddServiceEndpoint(typeof(IMyService), new NetNamedPipeBinding(), hostAddress);
host.Open();
Run Code Online (Sandbox Code Playgroud)
Chr*_*son 15
一个可能的答案你的问题"另一个应用程序,只需通过运行,打破我们自己的应用程序......":
我不知道Garmin服务是否确实使用了WCF NetNamedPipeBinding,但这是你应该调查的一种可能性.始终使用NetNamedPipe端点的绝对URL可以避免此问题.
好的,所以在问题更新之后,我们现在知道Garmin服务正在使用WCF NetNamedPipeBinding,并且我们知道您的应用程序使用绝对地址注册其服务,因此上述解释并非完整的故事.
这是另一个假设:
你能为这个做什么?我会建议:
小智 7
我们微软已经将问题归结为Garmin核心更新服务创建命名管道的方式.可以在不同的范围 - 全局和本地创建命名管道.全局范围本质上是机器范围的,而Local是特定于用户的.Garmin的应用是
一个.作为系统服务运行,因此侦听命名管道服务的范围是全局的.
湾 监听"net.pipe:// localhost /"的根地址(例如,没有任何子路径/段).
C.使用StrongWildcard主机名比较模式.
d.项目a到c意味着Garmin的应用程序基本上是任何与更具体的内容不匹配的网络管道连接的全能.
即 这也意味着Garmin完全阻止所有使用本地范围的侦听器
对此的理想修复是Garmin应用程序的更改,以便它使用更具体的URL注册其net.pipe侦听器.
我找到了一种方法来显示哪些应用程序使用net.pipe(虽然不一定正确使用它).
首先从sysinternals下载Handle应用程序:
https://technet.microsoft.com/en-us/sysinternals/handle.aspx?f=255&MSPPError=-2147217396
然后以管理员身份打开命令提示符,并运行"Handle.exe net.pipe"(减去引号).这将列出当前正在运行的net.pipe的所有应用程序.从那里,你可以一次杀死或禁用一个,直到你的罪魁祸首被发现.我几乎没有超过4-5个进程使用它.如果您无法以管理员身份运行命令提示符,则可能会给出0结果.
以下是我发现的干扰net.pipe的所有应用程序:
我支持需要net.pipe的应用程序,因此我会更新此列表,因为我找到了更多服务来执行此操作.