Problème de connexion inter-site auto-hébergé avec SignalR et Mono et Owin

Question

Je suis sur le point de me tirer d'affaire car tous les guides montrent la même ou les deux solutions qui semblent fonctionner pour tout le monde sauf moi-même. J'utilise SignalR dans une application Mono, en utilisant Owin. J'ai défini EnableCrossDomain = true dans mon HubConfiguration. J'ai mis en place une page de test simple en utilisant javascript pour me connecter. Les negotiate et ping sont en cours de chargement sans problème et semblent répondre correctement. Cependant, j'obtiens une erreur de domaine croisé sur l'appel connect.

Il utilise définitivement mon paramètre EnableCrossDomain car si je le mets à false, negotiate ne fonctionne pas.

Voici mon Javascript pour se connecter (et oui je suis compris le/signalr/moyeux de script qui renvoie le javascript approprié):

$.connection.hub.url = 'http://localhost:7001/signalr'; 
$.connection.hub.logging = true; 
$.connection.hub.start() 
    .done(function() { alert("Now connected!"); }) 
    .fail(function() { alert("Could not Connect!"); }); 

Aussi j'ai essayé jQuery.support.cors = true; aussi bien mais il ne fait pas toute différence.

J'ai aussi essayé la connexion à un PersistantConnection régulière comme si, avec le même problème, il ne semble pas être en relation directe avec les moyeux:

var connection = $.connection('/raw'); 
connection.url = 'http://localhost:7001/signalr'; 
connection.start() 
    .done(function() { alert("Now connected!"); }) 
    .fail(function() { alert("Could not Connect!"); }); 

Qu'est-ce que je fais mal ici? Pourquoi ping et negotiate fonctionnent mais pas connect?

---

EDIT: Aussi pour rendre les choses plus étrange, j'ai ajouté l'enregistrement et vérifié que la classe SignalR CallHandler ajoute l'en-tête Access-Control-Allow-Origin pour toutes les demandes, y compris la demande connect. Donc ça devrait marcher.

---

EDIT 2: Donc en fait grâce à gondoler il semble que le serveur renvoie un code de réponse 500, et comme il est pas aussi, y compris l'en-tête (ce qui doit se produire après le bloc de code, j'ai ajouté l'enregistrement à) , Chrome se plaint de cross site, alors qu'il y a probablement une exception quelque part dans le serveur. J'espère que je vais avoir compris cela sous peu et posterai une réponse ici.

Answer 1

Donc, il s'est avéré n'avoir rien à voir avec l'accès inter-site, et tout à voir avec les incompatibilités mono.

Après avoir activé la journalisation d'exception pour SignalR (https://stackoverflow.com/a/16577890/299262) j'ai eu l'exception suivante au lieu d'une http vierge erreur 500:

System.InvalidOperationException: The connection id is in the incorrect format. 
    at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId (Microsoft.AspNet.SignalR.Hosting.HostContext context, System.String connectionToken) [0x00000] in <filename unknown>:0 
    at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest (Microsoft.AspNet.SignalR.Hosting.HostContext context) [0x00000] in <filename unknown>:0 
    at Microsoft.AspNet.SignalR.Hubs.HubDispatcher.ProcessRequest (Microsoft.AspNet.SignalR.Hosting.HostContext context) [0x00000] in <filename unknown>:0 
    at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown>:0 
    at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown>:0 
    at Microsoft.AspNet.SignalR.Owin.Handlers.PersistentConnectionHandler.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown>:0 
    at Microsoft.Owin.Diagnostics.ShowExceptionsMiddleware.Invoke (IDictionary`2 environment) [0x00000] in <filename unknown> 

Cela m'a amené à trouver ce billet sur la liste des questions de mise en pension SignalR: https://github.com/SignalR/SignalR/issues/1914

donc à la fin, le correctif a été de commenter la ligne suivante dans HostDependencyResolverExtensions.cs:

resolver.InitializePerformanceCounters(instanceName, hostShutdownToken);