セルフホストアプリケーションでASP.NETWebAPIとSignalRを使用する可能性を調査してきましたが、ASP.NET Web APIセルフホスト実装はWCFを使用し、SignalRセルフホスト実装はを使用していることに気付きましたSystem.Net.HttpListener。これにより、組み合わせたセルフホスティングソリューションを思い付くのが少し難しくなりますが、プロジェクトチームごとに異なるアプローチを使用するのはなぜだろうと思います。
各アプローチの長所と短所は何ですか？SignalRがWCFセルフホスティングを使用できなかった、またはWeb APIがHttpListenerを使用できなかった特別な理由はありますか？
編集：Web APIセルフホスティングがSignalRよりも完全なスタックを提供することを理解しています。私の質問は、独自のセルフホスティングソリューションを実装するときにSystem.Net.HttpListenerではなくWCF実装を選択する理由についてです。
Web APIセルフホストはHTTPスタック全体を提供するため、System.Net.HttpListenerよりもはるかに豊富です。
SignalRはそれを使用して、独自の目的で通信ウィンドウを純粋に開きます。だから今のところ、異なるポートでそれらを並行して実行する必要があります。
将来的には、OWINを使用すると、すべてを1つの屋根の下に置くことができます。
編集：SignalR githubで発生した問題と同様の問題が実際にあり、答えは私が今言ったこととほぼ同じでした-https ://github.com/SignalR/SignalR/issues/277
同じページにいるので、Web APIセルフホストが使用するWCFセルフホストは、内部でHttpListenerを使用します。ただし、WCFセルフホストには大きな欠点があると思います。
これはまだ確認していませんが、Web API Self Hostを使用する場合、指定したベースアドレスが直接HttpListenerプレフィックスに変換されないようです。WCFはベースアドレスを変換し、ホストをワイルドカード化するようです。
これは、WCFセルフホストが指定されたポート上の任意のホストに応答することを意味します。これは、異なるホスト名を使用して、同じポートでIISと並行してWebAPIセルフホストサービスを実行できないことを意味します。
これが、SignalRがWCFセルフホストを廃棄してHTTPListenerを直接使用することを決定した理由である可能性があります。
WCFスタックを使用してサービスを自分でホストすることもできますが、「IIS 7.0HostableWebCore」を検討することをお勧めします。これには、ユーザープロセスでIISを実行できるという利点があります。このアプローチを使用すると、テクノロジーに関係なく、同じポートで複数のアプリケーションを実行できます。
興味のある方は、以下をご覧ください。
これはすべて、Vista以降を実行していることを前提としています...