在Windows 7和.NET 4上，当我的WCF客户端是Windows服务时，我从WCF命名管道传输中获得了一些非常奇怪的效果。
我的WCF服务托管在用户模式应用程序中，并通过命名管道绑定公开。
我的WCF客户端是一个Windows服务，作为网络服务运行（如果它作为本地系统运行，我得到相同的结果）。
如果我的用户模式应用程序（即WCF服务）作为域管理员运行，那么它可以正常工作，但如果用户模式应用程序是普通用户（或本地管理员），则通过CommunicationObjectFaultedException拒绝连接。
我在这里看到了一些与UAC有关的问题，但我还没有看到任何可以使命名管道传输正常工作的实际解决方案。这只是一个不可避免的框架错误吗？
答案 0 :(得分：4)
来自Christian Weyer的博客文章Dealing with OS privilege 'issues' in WCF Named Pipes scenarios：
如果我使用基于命名管道的端点的WCF服务器进程没有创建全局内核对象的权限，它将无提示失败并创建一个本地会话以外的进程无法看到的本地对象。
因此，没有创建全局内核对象权限的进程打开的基于命名管道的通信机制（WCF或其他）将无法从其自己的会话外部接收消息。
似乎这是意外后果法则的一个例子，其中对安全性的压制实际上导致人们通过被迫使用网络可见传输而不是本地机器IPC机制来打开更多安全漏洞。 MS应该为WCF提供合适的IPC通道，因为当前命名的管道传输不会削减它。
问题是，这不是一个特别不寻常的场景，因为.NET服务想要与.NET托盘应用程序通信以提供用户通知。从托盘应用程序到服务器的轮询机制将起作用......但是轮询速度慢且资源密集，我希望避免使用它。
任何人都知道更好的自定义IPC传输吗？
添