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

Question

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

我的WCF服务托管在用户模式应用程序中，并暴露在命名的管道绑定中。

我的WCF客户端是一个Windows服务，作为网络服务运行（如果它作为本地系统运行，我会得到相同的结果）。

如果我的用户模式应用程序（即WCF服务）作为域管理员运行，那么它工作正常，但如果用户模式应用程序是普通用户（或本地管理员），则连接将被拒绝，并出现CommunicationObjectFaultedException。

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

Answer 1

基督教维耶尔的博客文章Dealing with OS privilege 'issues' in WCF Named Pipes scenarios：

如果使用命名基于管道终点我的WCF服务器进程不具有的权限来创建一个全局内核对象，它静静地失败，并在本地创建一个这将对会话之外的进程不可见。

因此，没有创建全局内核对象的进程打开的基于命名管道的通信机制（WCF或其他）无法从其自己的会话外部接收消息。似乎是这是意外后果法则的一个例子，其中限制安全性实际上导致人们被迫使用网络可见传输而不是本地机器IPC机制来打开更多安全漏洞。 MS实际上应该为WCF提供一个合适的IPC通道，因为当前的命名管道传输不会削减它。

问题是，这不是一个特别不寻常的情况，因为.NET服务想要与.NET托盘应用程序交谈以提供用户通知。从托盘应用程序到服务器的轮询机制将工作......但轮询速度缓慢且资源密集，我想避免它。

任何人都知道更好的定制IPC运输？

Tim