asp.net-mvc - SignalR Sql Server/Owin 依赖问题

Question

我只是在这个问题的开头说我大约在 30 小时前开始使用 SignalR，所以请原谅任何业余问题，如果你知道一些，请随时指出我遗漏的文档。另外，我不是想写一篇博文——只是解释我所经历的步骤。

TLDR？跳到最后的问题...

我需要使用 Sql Server Backplane(很想使用 Redis，但我们目前不处理 Redis 并且不习惯在一个开发周期中引入太多新技术)。目前，没有适用于 Microsoft.AspNet.SignalR.SqlServer 的 NuGet 包。所以我必须使用 Github 源。

所以我去拉下源代码，编译并添加对 Microsoft.AspNet.SignalR.SqlServer.dll 的引用，但现在编译失败(特别是在我的代码中引用 GlobalHost.DependencyResolver.UseSqlServer( ... ) 时 - 这是一个依赖冲突，其中 *.SqlServer 代码是期待 *.SignalR.Core 的更新版本——这并不奇怪，因为自 NuGet 包发布以来，Github 的版本(毫无疑问)有不止一些变化)。 :(

所以下一步是使用 *.Core我用 *.SqlServer 编译的.下一个问题 - 新的 SignalR 版本不再适用于 *.Hosting.Common或 *.Hosting.AspNet已被替换为 *.Owin图书馆。

所以，我添加了 *.Owin (和 Owin - 来自 NuGet)但现在我遇到了另一个问题:MapHubs( ... )扩展方法不再有效 - 有名为 MapHubs( IAppBuilder builder, ... ) 的扩展方法在 Owin，但它们在 RouteTable 上不起作用不再 - 他们的工作 Owin.IAppBuilder (因此需要引用 Owin，我想)。

所以这就是我所在的位置。我做了一个关于 Owin 的快速阅读(似乎是一个很酷的概念)但我并不特别想花几个小时来解决这个问题，只是为了能够在服务器端设置 SignalR。那么，现在来回答问题:

我应该试着做 *.SqlServer与 SignalR 的旧 NuGet 包一起玩得很好(换句话说，更改 *.SqlServer 的依赖项是否可能会引入不可靠的行为)？或者，有没有*.SqlServer的版本哪个适用于已在线提供的当前 NuGet 发行版 SignalR？

通过 Owin 主机方法运行 SignalR 需要哪些具体步骤(如果没有加入 Nancy 集成，我找不到任何示例 - 或者这是正确的方法)？

MapHubs 方法的替代方法是什么？我从哪里获得 IAppBuilder？我什至应该这样做吗？

在 Google Groups post , David Fowler 指出，有了 Owin 支持，不再需要 AspNet 依赖项。很好 - 但是现在有什么理由在 ASP.Net MVC 应用程序中使用 SignalR 吗？

如果 SignalR 的任何部分都没有通过服务器上的 IIS 托管，那么客户端回退(即 SSE 或长轮询)是通过 IIS 还是独立使用 Owin 主机？

最后，我计划在作为另一个现有站点的虚拟目录托管的 ASP.Net MVC 4 项目中运行 SignalR - 我想在单个域中工作。当我的站点托管在 IIS 7.5 中时，使用 Owin 方法是否仍然可行？

更新:按照上面的 1.，我设法通过制作 *.SqlServer 来编译代码。取决于当前的 NuGet *.Core执行。所以现在我可以继续开发了。我不认为我想在生产中使用它 - 我只需要对处理对象进行一些小的更改 - 但我认为这不是一个好方法。所以我对 Owin 方法的疑问仍然存在——除非有人能让我相信我采用的方法是好的。

谢谢，
扎克

Answer 1

简答:

希望这会帮助其他遇到此问题的人(我确定你们中至少有一个人!):看来我问的问题真的很不合适，因为在发布几个小时后，SignalR 在 NuGet 中更新为版本 1.0.0-rc1。所以，对于任何有同样问题的人 - 只需升级包。

详情:

安装后，当您查看引用资料时，您会注意到现在有一​​个 Microsoft.AspNet.SignalR.SystemWeb引用。还没有深入研究，我认为这是 *.Hosting.Common 的替代品和 *.Hosting.AspNet因为更新后MapHubs( ... )扩展方法工作正常。

我还注意到 *.SystemWeb引用取决于 *.Owin - 所以我猜 Owin 引用被用作一个抽象层，它允许 SystemWeb 托管独立于底层 IIS/其他服务器实现。

至于.SqlServer引用，嗯，这仍然需要我针对 *.Core 的 NuGet 版本编译一个版本以便在本地编译。我现在将只使用它，并希望项目团队在不久的将来某个时候发布 NuGet 上的工作版本。

一个现实的替代方案是说服我的团队我们应该将 Redis 混为一谈——在其他项目中与 Redis 合作过，出于性能考虑，我认为这是一个不错的选择，但它确实需要 Linux，这对于一个项目来说可能是一个问题.Net团队...