Azure Service BusのドキュメントとWeb上の投稿を見ると、MessageReceiverクラスを使用して$DeadLetterQueueからデッドレターを読み取るデッドレター処理の例しか見つかりません。
上記のシナリオは正常に機能しますが、次のシナリオがサポートされているかどうか知りたいです。
別のWCFサービスエンドポイントを指定して、直接の配信不能キュー（sb：//mynamespace.servicebus.windows.net/MyTopic/subscriptions/MySubscription/$DeadLetterQueueなど）でメッセージを本質的にリッスンできますか？
新しいデッドレターが追加されると、このリスニングWCFサービスエンドポイントがトリガーされてメッセージが処理されることが期待されます。私がこれまでに行った実験は、これがサポートされていないことを示しています。
Azure Service Busがこの構成を処理できるかどうかを知っている人はいますか？
これはうまくいくはずで、試してみると思います。次のガイダンスを見たかどうかを知りたいだけです。WCFパブリッシュ/サブスクライブサービスモデルを使用する場合、サービスエンドポイントを追加するときは、トピックURIをアドレスとして指定する必要があります。リスニングURIとしてのサブスクリプションURI。リスニングURIをsb：//mynamespace.servicebus.windows.net/MyTopic/subscriptions/MySubscription/$DeadLetterQueueで置き換えることができるはずです。
申し訳ありませんが、現在、これに関するドキュメントが見つかりません。http://www.mygreatwindowsazureidea.com/forums/40626-windows-azure-appfabric-feature-votingで機能リクエストを送信できます。回避策として、MessageReceiverを使用してメッセージを読み取り、必要に応じてメッセージをWCFサービスに送信できます。