Windows 7 および .NET 4 では、WCF クライアントが Windows サービスの場合、WCF 名前付きパイプ トランスポートから非常に奇妙な効果が得られます。
私の WCF サービスはユーザー モード アプリでホストされ、名前付きパイプ バインディングを介して公開されます。
私の WCF クライアントは Windows サービスであり、ネットワーク サービスとして実行されます (ローカル システムとして実行されている場合も同じ結果が得られます)。
ユーザー モード アプリ (つまり、WCF サービス) がドメイン管理者として実行されている場合は正常に動作しますが、ユーザー モード アプリが通常のユーザー (またはローカル管理者) である場合、接続は CommunicationObjectFaultedException で拒否されます。
ここで UAC の関与に関連するいくつかの質問を見ましたが、名前付きパイプ トランスポートを適切に機能させる実際の解決策はどこにも見当たりませんでした。これは避けられないフレームワークのバグですか?
Christian Weyer のブログ エントリ、WCF 名前付きパイプ シナリオでの OS 特権の「問題」への対処:
名前付きパイプ ベースのエンドポイントを使用する WCF サーバー プロセスに、グローバル カーネル オブジェクトを作成する権限がない場合、サイレントに失敗し、セッション外のプロセスからは見えないローカル オブジェクトが作成されます。
そのため、グローバル カーネル オブジェクトを作成する権限のないプロセスによって開かれた名前付きパイプ ベースの通信メカニズム (WCF またはその他) は、それ自体のセッションの外部からメッセージを受信することはできません。
これは意図しない結果の法則の一例であると思われます。セキュリティを取り締まると、実際には、ローカル マシンの IPC メカニズムの代わりにネットワークから見えるトランスポートを使用することを余儀なくされ、より多くのセキュリティの抜け穴が開くことになります。現在の名前付きパイプ トランスポートでは対応できないため、MS は WCF に適切な IPC チャネルを提供する必要があります。
問題は、.NET サービスがユーザー通知を提供するために .NET トレイ アプリと通信したい場合、これが特に珍しいシナリオではないことです。トレイアプリからサービッドへのポーリングメカニズムは機能します...しかし、ポーリングは遅く、リソースを大量に消費するため、避けたいと思います。
より優れたカスタム IPC トランスポートを知っている人はいますか?
ティム