为什么命名管道WCF服务拒绝Windows服务客户端？

在 Windows 7和.NET 4上,当我的WCF客户端是Windows服务时,我从WCF命名管道传输中获得了一些非常奇怪的效果.

我的WCF服务托管在用户模式应用程序中,并通过命名管道绑定公开.

我的WCF客户端是一个Windows服务,作为网络服务运行(如果它作为本地系统运行,我得到相同的结果).

如果我的用户模式应用程序(即WCF服务)作为域管理员运行,那么它工作正常,但如果用户模式应用程序是普通用户(或本地管理员),则通过CommunicationObjectFaultedException拒绝连接.

我在这里看到了一些与UAC有关的问题,但我还没有看到任何可以使命名管道传输正常工作的实际解决方案.这只是一个不可避免的框架错误吗？

If my WCF server process using a Named Pipe-based endpoint doesn’t have privileges to create a Global kernel object it silently fails and creates a local one which will not be visible to processes outside of its session.

因此,没有创建全局内核对象特权的进程打开的基于命名管道的通信机制(WCF或其他)将始终能够从其自己的会话外部接收消息.

似乎这是意外后果法则的一个例子,其中对安全性的压制实际上导致人们通过被迫使用网络可见传输而不是本地机器IPC机制来打开更多安全漏洞. MS应该为WCF提供合适的IPC通道,因为当前命名的管道传输不会削减它.

问题是,这不是一个特别不寻常的场景,因为.NET服务想要与.NET托盘应用程序通信以提供用户通知.从托盘应用程序到服务器的轮询机制将起作用……但是轮询速度慢且资源密集,我希望避免使用它.

谁知道更好的定制IPC运输？

蒂姆

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!