Связь SignalR между различными платформами .net

В настоящее время у меня есть проект WCF с .NET 4.6.1 и проект .NET Core, через который я запускаю веб-службу и приложение Angular 2. При попытке сослаться на проект AspNetCore.SignarlR (из проекта WCF) с использованием класса HubConnection при запуске соединения я всегда получаю сообщение об ошибке:

При синтаксическом анализе значения обнаружен неожиданный символ: ‹. Путь '', строка 0, позиция 0.

Приложение Angular успешно использует службу SignalR для демонстрации чата. Я определенно определил свою маршрутизацию в правильном порядке, и имя моего концентратора в проектах также было дважды проверено.

Может ли ошибка, которую я получаю, быть связана с тем, что я использую две разные реализации библиотеки SignalR? Если да, то есть ли способ решить эту проблему?


person envio    schedule 30.10.2017    source источник


Ответы (1)


Версия SignalR для ASP.NET Core несовместима с предыдущей версией. Обратите внимание, что клиент ориентирован на netstandard, поэтому вы сможете использовать .NET Client из ASP.NET Core версии SignalR в своем проекте.

Сказав это - я думаю, что вы еще не столкнулись с несовместимостью версий. Сообщение об ошибке жалуется на символ <, который говорит мне, что сервер обслуживает либо XML, либо HTML (возможно, ошибка), в то время как клиент (либо старый, либо новый) ожидает JSON в первом ответе. Вам нужно сначала проверить, какой ответ вернул сервер, чтобы понять, что происходит.

person Pawel    schedule 30.10.2017
comment
Спасибо, да, вы правы, вместо этого возвращается HTML-документ. Что интересно, если я создаю веб-запрос на стороне сервера к localhost:50114/myhub, он успешно возвращает действительный json ответ с идентификатором соединения. Если я использую HubConnection(localhost:50114/myhub, false); подход, идентификатор соединения всегда равен нулю - person envio; 31.10.2017
comment
Что в HTML? Вы локально используете IIS или просто Kestrel? Может быть, это неправильная конфигурация IIS? - person Pawel; 31.10.2017
comment
Наконец-то мне удалось увидеть, что клиент совершал вызов, который имел множество различных параметров строки запроса, которые включали что-то о согласовании. Приложение Angular сделало вызов, который не включал этот параметр, поэтому конвейер обработал его правильно. Я предполагаю, что URL-адрес не соответствует тому, что ожидала версия signalr aspnetcore. Возвращаемый HTML был просто страницей по умолчанию из приложения Angular. На данный момент я согласился с тем, что этот подход, вероятно, не лучший на данный момент. - person envio; 02.11.2017