asp.net-mvc - net - signalr hubconnectionbuilder()

IE 11+SignalR no funciona

Question

Se está produciendo un comportamiento extraño al usar signalR con IE 11. Escenario:

Tenemos algunas funciones de tipo despachador en las que el despachador realiza algunas acciones y el otro usuario puede ver las actualizaciones en tiempo real (consultas). Los parámetros que se envían vienen bien y causan actualizaciones en el lado del cliente IE sin tener que abrir la consola del desarrollador.

PERO el único método que no funciona ( performUpdate - para obtener los resultados de la consulta - este es un servidor> cliente, no cliente> servidor>) nunca recibe una llamada. SOLO SE LLAMA CUANDO LA CONSOLA DEL DESARROLLADOR ESTÁ ABIERTA.

Esto es lo que he intentado:

¿Por qué JavaScript solo funciona después de abrir las herramientas de desarrollador en IE una vez?

SignalR: bajo IE9, los mensajes no pueden ser recibidos por el cliente hasta que llegue a F12 !!!!

El cliente SignalR no funciona dentro del controlador AngularJs

Algunos fragmentos de código

Lado del despachador

En el cambio desplegable, obtenemos los valores seleccionados actualmente y enviamos actualizaciones a través del cable. (Esto funciona bien).

$(''#Selector'').on(''change'', function(){
var variable = $(''#SomeField'').val();
...
liveBatchHub.server.updateParameters(variable, ....);
});

Lado del servidor

Cuando el despachador realiza una búsqueda, tenemos un código del lado del servidor que envía notificaciones de que se ha ejecutado una búsqueda y le indica al cliente que obtenga resultados.

public void Update(string userId, Guid bId)
{
var context = GlobalHost.ConnectionManager.GetHubContext<LiveBatchViewHub>();
context.Clients.User(userId).performUpdate(bId);
}

Lado del cliente (visor de actualizaciones en vivo)

Esto nunca se llama a menos que las herramientas de desarrollador estén abiertas

liveBatchHub.client.performUpdate = function (id) {
//perform update here
update(id);
};

Editar

Un poco más de información que podría ser útil (no estoy seguro de por qué marca la diferencia) pero esto SOLO parece suceder cuando estoy haciendo llamadas de servidor> cliente. Cuando el asignador está cambiando los parámetros de búsqueda, la actualización es cliente> servidor> cliente o despachador-cliente> servidor> visor-cliente, que parece funcionar. Después de hacer clic en buscar, un servicio en la canalización de búsqueda llama al lado del servidor de performUpdate (servidor> viewer-client). ¿No estoy seguro si esto importa?

Editar 2 y solución final

Con los ojos inyectados en sangre, me doy cuenta de que dejé fuera una parte clave de esta pregunta: estamos usando angular también en esta página. Supongo que lo he estado mirando demasiado tiempo y lo dejé, lo siento. Le concedí la respuesta a JDupont porque estaba en el camino correcto: el almacenamiento en caché. Pero no el almacenamiento en caché ajax de jQuery, angulares $ http.

Para que nadie más tenga que pasar días / noches golpeando sus cabezas contra el escritorio, la solución final fue deshabilitar el almacenamiento en caché de llamadas ajax usando angulares $ http.

Tomado desde here :

myModule.config([''$httpProvider'', function($httpProvider) {
//initialize get if not there
if (!$httpProvider.defaults.headers.get) {
$httpProvider.defaults.headers.get = {};
}
// Answer edited to include suggestions from comments
// because previous version of code introduced browser-related errors
//disable IE ajax request caching
$httpProvider.defaults.headers.get[''If-Modified-Since''] = ''Mon, 26 Jul 1997 05:00:00 GMT'';
// extra
$httpProvider.defaults.headers.get[''Cache-Control''] = ''no-cache'';
$httpProvider.defaults.headers.get[''Pragma''] = ''no-cache'';
}]);

Answer 1

He experimentado un comportamiento similar en IE en el pasado. Puedo saber de una solución a tu problema.

IE almacena en caché algunas solicitudes ajax por defecto. Es posible que desee intentar desactivar esto globalmente. Mira esto: Cómo evitar que IE almacene en caché Ajax con jQuery

Básicamente, debes desactivar esto de la siguiente manera:

$.ajaxSetup({ cache: false });

o para una solicitud específica de ajax como esta:

$.ajax({
cache: false,
//other options...
});

Tuve un problema similar con el almacenamiento en caché de mis solicitudes GET. Mi función de actualización solo se activará una vez a menos que las herramientas dev estén abiertas. Cuando estaba abierto, no se producía el almacenamiento en caché.

Answer 2

Si su código funciona correctamente con otros navegadores, entonces el problema puede ser del método de transporte utilizado por SignalR. Pueden ser WebSocket , eventos enviados por el servidor , Forever Frame y Long Polling basados ​​en el soporte del navegador.

Forever Frame es solo para Internet Explorer. Puede ver la Introducción a SignalR para saber qué método de transporte se utilizará en varios casos (Tenga en cuenta que no puede usar ninguno de ellos en cada navegador, por ejemplo, IE no admite eventos enviados por el servidor ).

Puede comprender el método de transporte que se utiliza dentro de un concentrador simplemente mirando el QueryString la solicitud que puede ser útil para el registro:

Context.QueryString["transport"];

Creo que el problema proviene del uso de Forever Frame por IE, ya que a veces hace que SignalR falle en las llamadas Ajax. Puede intentar eliminar el soporte de Forever Frame en SignalR y forzar el uso de los métodos soportados restantes por el navegador con el siguiente código en el lado del cliente:

$.connection.hub.start({ transport: [''webSockets'', ''serverSentEvents'', ''longPolling''] });

Mostré algunas realidades sobre SignalR y le di algunas herramientas de registro / rastreo para resolver su problema. Para obtener más ayuda, ingrese detalles adicionales :)

Actualización : Dado que su problema parece ser muy extraño y no tengo suficiente visión alrededor de su código, entonces le propongo algunas instrucciones basadas en mi experiencia para ser útil:

1. Configurar el enlace del navegador en IDE adecuado
2. verificar los datos de solicitud / respuesta de la pestaña de red durante su proceso
3. Asegúrese de no haber usado nombres reservados en su servidor / cliente (quizás cambiando el nombre de métodos y variables)

También creo que necesitas usar liveBatchHub.server.update(variable, ....); en lugar de liveBatchHub.server.updateParameters(variable, ....); en el lado de Dispatcher para hacer llamadas al servidor, ya que debe usar el nombre del método del server después del server .