Windowsサービスで複数のWCFサービスをホストしています。これらのWCFサービスの1つは、同じWindowsサービスでホストされている別のWCFサービスを呼び出す必要があります。これは、同じマシンまたは別のマシンにインストールされた同じWindowsサービスで実行する必要があります。自分自身への参照を追加するにはアプリケーションが必要ですか、それとも独自のサービスを呼び出すための簡単な方法がありますか？私は、エンドポイントアドレスを変更することによって異なるマシンビットを行う方法を知っていますが、自分自身への参照を追加するべきかどうかについてあまり明確ではありません。つまり、別のクライアントから使用するのと同じコードを使用する必要があります。.NETサービスホストが独自のサービスを呼び出す
ここでの概念は「位置透明性」と呼ばれます。つまり、同じプロセスまたは別のマシンで稼働する（WCF）サービスを呼び出す際に（技術的な）違いはありません。
一般的には、ニーズ（安定性や個々のサービスのリソース消費）に応じて、展開後または展開中にサービスの場所を変更できるため、これは良いことです。
Named Pipe Bindingを設定することで、同じマシン上で実行していることを最適化することができます。実際の作業と実際の作業の実行時間によって異なります。適切なバインディングの選択に関する詳細は/ hereを参照してください）。
最後に、それ本当に問題ならば、あなたはおそらく事実を利用して、あなたのown bindingを作成することができ、同じプロセス内の両方のサービスの人生 - 最も可能性が高いではない簡単な仕事。
しかし、実際のサービス実装が使用されているトランスポートまたはバインディングに依存しないようにして、場所の透過性を保持する必要があります。
WCFサービスにアクセスする場合は、処理中であるかどうかにかかわらず、プロキシを生成することは良いアイデアであり、簡単な方法です。
ChannelFactoryを使用してサービスにChannelを直接作成することはできますが、これは必須ではありません。しかし、できる場合は、なぜそれのためのプロキシを生成しないでください？
新しいキーワードでサービスの新しいインスタンスを作成できます（サービスの具体的な実装をターゲットにしています - もちろんインターフェイスではありません）。私はこれを常に行い、それはうまく動作します。 また、プロジェクトは自分自身への参照を追加することも、スペース時間の連続でリッピングを引き起こすこともできません）。
これはもちろん、トランザクション、セキュリティなどのためのWCFのインフラストラクチャを迂回します。OPの状況には問題はありませんが、一般的には「悪いアイデア」と考えています。 –
質問が提起された状況を考えて、私はOPが高レベルのアプリケーション（嫌なOPはない）を開発していると仮定していないので、彼を助け、地獄を混乱させないようにするための提案をしました。 また、呼び出しが同じプロセス内にあるという事実は、ここでのセキュリティは問題ではないことを示唆しました。 「すべての母親」の解決策がすべての問題に存在することを覚えておいてください。それらは常に適用可能ではありません:) –
ありがとうございます。もともと、自分自身への参照を追加するというコンセプトは奇妙に見えましたが、それは理にかなっていました。 – Jonnster