SignalR Sql Server/Owin Dependency Issues

3
votes

I'll just preface this question by saying I began working with SignalR around 30 hrs ago, so please forgive any amateur questions and feel free to point me to the documentation that I've missed if you know of some. Also, I'm not trying to write a blog post - just explaining the steps I went through to get where I am.

TLDR? skip to the questions at the end...

I need to use the Sql Server Backplane (would love to use Redis but we don't currently deal with Redis and aren't comfortable introducing too many new technologies in one dev cycle). Currently, there isn't a NuGet package available for Microsoft.AspNet.SignalR.SqlServer so I have to work with the Github source.

So I went and pulled down the source, compiled and added the reference to Microsoft.AspNet.SignalR.SqlServer.dll but now compilation fails (specifically when referencing GlobalHost.DependencyResolver.UseSqlServer( ... ) in my code - it's a dependency conflict where the *.SqlServer code is expecting a more recent version of *.SignalR.Core - not really surprising as Github's version has (no doubt) more than a few changes since the NuGet package was released). :(

So the next step is to use the *.Core which I compiled with *.SqlServer. Next problem - the new SignalR version no longer works with *.Hosting.Common or *.Hosting.AspNet which have been replaced with the *.Owin library.

So, I added *.Owin (and Owin - from NuGet) but now I run into yet another problem: the MapHubs( ... ) extension method no longer works - there are extension methods called MapHubs( IAppBuilder builder, ... ) in Owin but they don't work off the RouteTable anymore - they work of Owin.IAppBuilder (hence the need to reference Owin, I suppose).

So this is where I'm at. I did a quick read-up about Owin (seems like a cool concept) but I don't particularly care to spend some hours getting my head around that just to be able to setup SignalR on the server-side. So, now for the questions:

  1. Should I just try to make *.SqlServer play nice with the older NuGet packages of SignalR (in other words, is it likely that changing the dependencies of *.SqlServer will introduce unreliable behaviour)? Or, is there a version of *.SqlServer which works with the current NuGet release version of SignalR available online already?
  2. What specific steps are needed to run SignalR via the Owin host approach (I can't find any examples for this without, say, Nancy integration thrown in - or is that the correct approach)?
  3. What is the replacement approach for the MapHubs method? Where do I get an IAppBuilder from? Am I even supposed to do so?
  4. In a Google Groups post, David Fowler indicates that, with Owin support, the AspNet dependency is no longer required. That's fine - but is there any reason to use SignalR in an ASP.Net MVC app now?
  5. If no part of SignalR is hosted via IIS on the server, does client-side fallback (i.e. SSE or long-polling) go through IIS or does it use the Owin host independently?
  6. Finally, I was planning to run SignalR off an ASP.Net MVC 4 project being hosted as a virtual directory off another existing site - I want to work within a single domain. With the Owin approach is it still feasible to do this when my site is hosted in IIS 7.5?

UPDATE: As per 1. above, I managed to get the code compiling by making *.SqlServer depend upon the current NuGet *.Core implementation. So now I can continue development. I don't think I want to use this in production though - I only had to make a small change relating to disposing an object - but I just don't think it's a good approach. So my questions around the Owin approach still stand - unless someone can convince me that the approach I've taken is fine.

Thanks, Zac

1
asp.net-mvcsignalr
This type of questions is too broad. Instead, try to ask different specific questions then people might actually want to answer. – davidfowl
Yeah, I understand what you're saying David - I usually try to be as specific as possible with SO questions. The problem is, I've been unsuccessful at finding any useful information relating to the problems outlined - so I don't really know where to start. I know you guys are still working on the next release and that development is, rightfully, a more important focus than documentation but without working examples it's hard to even know what to ask. – Zac Seth
Also, while questions 2 and 5 are perhaps overly general (I'll see about removing/improving them now), there are some (questions 1, 3, 4, and 6) which are, IMHO, quite specific... – Zac Seth
Still, nobody is going to reply. If you want to discuss something head over to jabbr.net/#/rooms/signalr – davidfowl

1 Answers

1
votes

Short Answer:

Hopefully this will help others out who have this problem (I'm sure there's at least one of you!): it seems that the question I asked was really badly timed as, a couple of hours after posting, SignalR was updated in NuGet to version 1.0.0-rc1. So, to anyone with the same problem I had - just upgrade the package.

Details:

After installing when you look at the references, you'll notice that there's now a Microsoft.AspNet.SignalR.SystemWeb reference. Without having delved into it yet, I'm thinking this is a replacement for *.Hosting.Common and *.Hosting.AspNet because after updating the MapHubs( ... ) extension method works fine.

I also noted that the *.SystemWeb reference depends on *.Owin - so I guess the Owin reference is used as an abstraction layer which allows the SystemWeb hosting to be independent of underlying IIS/other server implementations.

As for the .SqlServer reference, well, that still requires me to compile a version against the NuGet version of *.Core in order to compile locally. I'm going to just work with that for now and hope that the project team release a working version on NuGet sometime in the near-future.

A realistic alternative would be to convince my team that we should throw Redis into the mix - having worked with Redis on other projects, I consider this to be a good option due to performance considerations however it does require Linux which might be a problem for a .Net team...