2011-05-26 3 views
5

Я могу успешно подключиться к удаленной службе WCF с консоли или веб-сайта/веб-приложения, запущенного на VS-dev-сервере. Однако, когда я пытаюсь подключиться с веб-сайта IIS, я получаю следующую ошибку. Есть идеи?Не удается подключиться к удаленной службе wcf из IIS

No connection could be made because the target machine actively refused it 12.11.121.12:80

ответ

4

Эта ошибка:

No connection could be made because the target machine actively refused it

Означает, что запрос на соединение успешно прошел к целевой машине (это не вопрос брандмауэра), на данный порт и целевая машина не слушает для входящих соединений на этом порту, поэтому ОС отказалась от попытки подключения.

Остальная часть вашей ошибки определяет аппарат 12.11.121.12 и номер порта 80, на котором было произведено соединение.

Ошибка указывает, что сервер не запущен на целевой машине. Если вы знаете, сервер работает на компьютере, к которому вы пытаетесь подключиться, потому что вы можете подключиться к нему из другого приложения, тогда это говорит о том, что данные вашего соединения неверно настроены на веб-сайте.

Так, некоторые вещи, чтобы проверить:

  • Существуют ли какие-либо различия между App.config/подробности конфигурации web.config для целевого веб-сервиса? В частности, имя машины (12.11.121.12) и номер порта (80) будут казаться потенциальными.
  • Запускаете ли вы размещенный веб-сайт IIS на том же компьютере, что и консольное/веб-приложение? Если нет, то обе машины разрешить имя целевого сервера (вы используете someserver.org, например, а не 12.11.121.12 и решается на другой IP, поскольку один сервер наружной облицовке, а другой является внутренним?
+0

Спасибо за ваш ответ. Я начал изучать конфигурацию, особенно после вашего ответа. Наши компьютеры настроены через прокси-сервер, поэтому я подумал, что это может быть проблемой .. Я изменил некоторые параметры в элементе привязки, например bypassProxyOnLocal = "false" useDefaultWebProxy = "false" proxyAddress = "http: // proxyaddress: portno" в сети .config и сразу начали работать. Мне интересно, почему об этом никто не думал. – VJAI

+0

@Vijaya Anand: Рад, что у вас это работает.Прокси, безусловно, один из самых простых способов в конечном итоге разговора с другой машиной с той, которую вы считали собой :) – forsvarir

+1

@Mark: Несколько вещей вокруг этикета сайта, так как ваша проблема, похоже, решена. Если вы нашли мой ответ полезным для решения вашей проблемы, это, как правило, вежливо, чтобы повысить его. Если вы не собираетесь принимать его и/или присуждать награду (что разумно, так как я не упомянул вашу точную проблему), тогда вам следует рассмотреть возможность публикации своего ответа и принятия того, чтобы вместо этого указать, что проблема была разрешено и как. Если, с другой стороны, вы надеетесь на дальнейшую помощь, вы можете опубликовать обновление своего вопроса, чтобы указать, какие у вас проблемы. – forsvarir

0

Это звучит так как пул приложений работает под другим пользователем (машиной) по умолчанию. Поскольку WCF использует токен аутентификации, я буду держать пари, что это ваша проблема. Попробуйте установить личность пула на то же самое пользователь как консоль, и я уверен, что он будет работать нормально.

+0

Эта целевая машина с ошибкой активно отказывается от нее, если целевая машина не прослушивает порт, на котором выполняется попытка подключения (в этом случае из-за настроек прокси-сервера см. Комментарий ops в моем ответе). Если бы это была проблема с разрешениями, ошибка скорее всего была бы чем-то вроде «отказа в разрешении» или «сбоя аутентификации», но этот уровень проверки не выполняется до тех пор, пока * после * соединения не будет установлено. – forsvarir

+0

Хорошая точка, спасибо за ясность – hivie7510

0

Странно я получил эту ошибку, когда useDefaultWebProxy был «истинным» из веб-приложения, но точно такой же код и настройки работали нормально в единичном тесте c деваха.

Оказалось, что веб-приложение использует прокси-сервер (корпоративная политика) веб-браузера https://foo/bar:1234. Когда я установил это явно с помощью:

<system.serviceModel> 
    <bindings> 
    <wsHttpBinding> 
     <binding name=... 
      useDefaultWebProxy="false" proxyAddress="https://foo/bar:1234" 
     ... 

я получил ошибку:

The ServicePointManager does not support proxies with the https scheme

Так что я изменил адрес прокси-сервера для HTTP, а не по протоколу HTTPS, и это сработало.

Смежные вопросы