First off - awesome work!
We're making use of IConnectionManager.GetConnection() to obtain a connection from outside the SignalR "pipeline" however as this returns IConnection rather than an instance of T we can't perform a SendToGroup etc.
We've worked around this currently by duplicating the implementation of SendToGroup including CreateQualifiedName and marking it with a big // HACK comment.
Wondering whether there's a particular architectural reason why you get IConnection from this method and what you would recommend we do in this case.
The IConnection API needs some clean up. You can't get a reference to the PersistentConnection since it has some thing that don't make sense on it outside the scope of the connection.
Will be part of this clean up work #20
Some kind of "in-memory" transport might be appropriate - effectively using the client library from the same machine but without the networking and request stuff going on.
@dezfowler You lost me completely. What does that have to do with this bug?
Our particular use case that led us to this issue was that we were effectively making a client call from the SignalR hosting machine itself i.e. within our MVC code. So a connection scope probably does make sense at some level but an in-memory rather than network-based connection.
I don't see how that's relevant but sure. I understand the general question and issue. That's why I linked to the other bug.
This method is for when the server is trying to brodcast, basically within the same app domain you wouldn't use the client in that scenario.
Made some changes to the APIs for the upcoming 0.5. You can try out the prerelease on this nuget feed: