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