通过命名管道从Windows服务(会话#0)连接到桌面应用程序(会话#1) [英] Connecting via named pipe from windows service (session#0) to desktop app (session #1)

问题描述

给出:
-应用程序-桌面GUI(WPF).NET应用程序
-Windows服务监视应用程序(也包括.NET)

Given:
- the application - desktop GUI (WPF) .NET app
- windows service watching for application (.NET also)

Windows服务会定期"ping"应用程序，以确保其运行状况良好(如果不是，则winservice会重新启动它).
我打算通过命名管道实现"ping".为了简化起见，我决定使用WCF.该应用程序承载WCF服务(一个操作Ping返回了一些内容). Windows服务是此WCF服务的客户端，它会根据计时器定期调用它.

The windows service periodically "pings" application to get sure it's healthy (and if it's not winservice will restart it).
I was going to implement "pinging" via named pipes. To make things simpler I decided to do it with WCF. The application hosts a WCF-service (one operation Ping returning something). The windows service is a client for this WCF-service, invokes it periodically based on a timer.

Windows 7就是这样.
Windows服务在LocalService(在会话#0中)下运行.
桌面应用程序正在当前登录的用户(在会话#1)下运行.

That's all in Windows 7.
Windows service is running under LocalService (in session#0).
Desktop application is running under currently logged in user (in session#1).

问题:
Windows服务无法看到在桌面应用程序中创建并正在监听的WCF端点(带有NetNamedPipeBinding).这意味着在通过wcf代理进行调用时，我遇到以下异常:在本地计算机上找不到管道终结点'net.pipe://localhost/HeartBeat'"

The problem:
Windows service can't see WCF endpoint (with NetNamedPipeBinding) created in and being listened in desktop application. That means that on call via wcf proxy I get this exception: "The pipe endpoint 'net.pipe://localhost/HeartBeat' could not be found on your local machine"

我确定代码是可以的，因为另一个桌面应用程序(在会话#1中)可以看到端点.

I'm sure code is ok, because another desktop application (in session#1) can see the endpoint.

很显然，这里我正在处理一些用于Win32系统对象隔离的安全性内容. 但是我相信应该有一种方法可以解决我遇到的限制.
我可以牺牲WCF方法，而采用原始的NamedPipe方法.

Obviously here I'm dealing with some security stuff for Win32 system object isolation. But I believe there should be a way to workaround restrictions I've encountered with.
I can sacrifice WCF approach and go the raw NamedPipe way.

推荐答案

更简单的解决方案可能是将WCF双工合同与托管WCF服务的Windows服务一起使用.客户端应用在启动时会调用该服务上的一个操作进行注册.然后，Ping将是服务在客户端的回调合同上由服务定期调用的操作，App会对此进行响应.

An easier solution might be to use a WCF duplex contract with the Windows service hosting the WCF service. The client App would call an operation on the service to register itself, when it starts up. The Ping would then be an operation invoked periodically by the service on the client's callback contract, to which the App would respond.

服务可见性以这种方式工作，因为Windows服务可以与SeCreateGlobalPrivilege一起运行，因此可以在全局内核名称空间中创建该服务通过其发布管道名称的共享内存对象，其他会话可以看到该对象.交互式应用程序无法轻松地在Windows7中获得该特权，因此此类应用程序中的WCF服务会退回到在本地内核名称空间中发布管道(仅在其自己的会话中可见).

Service visibility works this way round, because the Windows service can run with SeCreateGlobalPrivilege, and so the shared memory object via which the pipe name is published by the service can be created in the Global kernel namespace, visible to other sessions. Interactive applications can't easily get that privilege in Windows7, so WCF services in such applications fall back to publishing the pipe in the Local kernel namespace, visible only within their own session.

这篇关于通过命名管道从Windows服务(会话#0)连接到桌面应用程序(会话#1)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！