4

我一直在研究在自托管应用程序中使用 ASP.NET Web API 和 SignalR 的可能性，我注意到 ASP.NET Web API 自托管实现使用 WCF，而 SignalR 自托管实现使用System.Net.HttpListener. 这使得想出一个组合的自托管解决方案变得有点困难，但这确实让我想知道为什么不同的项目团队会使用不同的方法。

每种方法的优点和缺点是什么？SignalR 不能使用 WCF 自托管，或者 Web API 不能使用 HttpListener 有什么特别的原因吗？

编辑：我知道 Web API 自托管提供了比 SignalR 更完整的堆栈，我的问题更多是关于为什么在实现自己的自托管解决方案时选择 WCF 实现而不是 System.Net.HttpListener。

4

3 回答 3

6

Web API 自托管提供了整个 HTTP 堆栈，因此它比 System.Net.HttpListener 丰富得多。

SignalR 使用它来纯粹为自己的目的打开一个通信窗口。所以是的，现在，你需要在不同的端口上并行运行它们。

未来，有了 OWIN，您将拥有一切。

编辑：实际上有一个类似于你在 SignalR github 上提出的问题，答案就是我刚才所说的 - https://github.com/SignalR/SignalR/issues/277

于 2012-09-04T08:20:17.767 回答
3

就像我们在同一页面上一样，Web API Self 主机使用的 WCF Self-host 确实在幕后使用了 HttpListener。但是，我想我可能发现了 WCF Self-host 的一个主要缺点。

我还没有确认这一点，但似乎当您使用 Web API Self Host 时，您提供的基地址不会直接转换为 HttpListener 前缀。看起来 WCF 翻译了主机的基地址和通配符。

这意味着 WCF 自主机将响应指定端口上的任何主机。这意味着您不能在同一端口上使用不同的主机名同时运行 Web API 自托管服务和 IIS。

这可能是 SignalR 决定废弃 WCF Self-Host 并直接使用 HTTPListener 的原因。

于 2012-11-10T15:02:46.873 回答
2

虽然您可以使用 WCF 堆栈自己托管服务，但您可能需要考虑“IIS 7.0 Hostable Web Core”。它的好处是在您的用户进程中运行 IIS。使用这种方法，您可以在同一个端口上运行多个应用程序，而与技术无关。

有兴趣的可以看看：

  1. 使用 IIS 7.0 Hostable Web Core 在您的应用程序中托管您自己的 Web 服务器
  2. 创建托管 Web 核心应用程序

这一切都假设您正在运行 Vista 或更高版本...

于 2012-09-04T20:56:07.197 回答