Я пытался заставить мое приложение Silverlight работать с привязкой WCF net.tcp целый день и не смог этого сделать, хотя мне кажется, что я все сделал правильно, в том числе после некоторого поиска в Google ... .
У меня был сервис WCF с базовой конечной точкой HttpBinding, который работал отлично, и поскольку моя служба WCF и мое приложение Silverlight находятся в одной сети, я сказал себе «почему бы не попробовать что-то еще, кроме HTTP?»
Итак, я начал гуглить, чтобы увидеть, что нужно было сделать, и вот список того, что я сделал:
Сервер
- Проверено, что служба адаптера прослушивателя Net.Tcp работает
IIS
- Включена привязка net.tcp на моем веб-сайте, для информации о привязке установлено значение "4502: *"
- Добавлен протокол net.tcp в приложение, в котором размещена моя служба WCF
- В файле clientaccesspolicy.xml добавлена политика, разрешающая подключение к сокету через порты 4502-4536
Служба WCF
- Добавлена привязка net.tcp с безопасностью, установленной на None
- Добавил конечную точку с этой привязкой для моей службы, сохранив обычную HTTP
После всего этого я могу использовать свой сервис WCF с WcfTestClient, он видит две конечные точки (HTPP и net.tcp), и обе они работают как чудо.
В моем приложении Silverlight я могу обновить свою ссылку на службу (которую я добавил с помощью HTTP-адреса моей службы, а не TCP), и он также видит две конечные точки, поскольку он добавил конечную точку TCP в ServiceReferences.ClientConfig. , Как я видел при поиске, netTcpBinding не поддерживается в Silverlight, поэтому он описывает привязку как настраиваемую привязку с элементом a и.
В различных руководствах, которые я использовал, я видел, что для привязки HTTP Silverlight запрашивает файл политики сокетов, чтобы проверить, имеет ли клиент доступ к службе WCF. В бета-версии SL4 этот файл запрашивался TCP на порту 943. Что касается SL4 RC и RTM, он запрашивается HTTP на порту 80, как и для привязок HTTP.
Дело в том, что когда я запускаю свое приложение с прокси-сервером, настроенным на использование привязки net.tcp, я проверил с помощью Fiddler, clientaccesspolicy.xml запрашивается NOT в любое время, и я получаю classic ошибка, когда файл политики сокета отсутствует: код ошибки TCP 10013: была предпринята попытка получить доступ к сокету способом, запрещенным его правами доступа.
После поиска в Google я обнаружил, что SL ищет этот файл с IP-адресом сервера, а не с его именем, но при попытке http://IP_OF_MY_SERVER/clientaccesspolicy.xml в браузере на моей клиентской машине файл, как и ожидалось, обрабатывается ...
Так что я немного растерялся, мне бы очень хотелось, чтобы он работал, чтобы увидеть что-то еще, кроме HTTP с WCF ...
Кто-то может догадаться, что происходит ???
Поскольку служба работает, как и ожидалось, с WcfTestCLient с привязкой net.tcp, я предполагаю, что это как-то связано именно с SL ...
Спасибо за чтение: -)