Устранение проблем с несколькими конечными точками в WCF

Question

Я использую WCF уже несколько лет, и мне это довольно удобно, однако есть одна простая концепция WCF, которую мне еще предстоит применить, и я испытываю трудности с ней.

После этой статьи об адресации WCF, поскольку она конкретно относится к нескольким конечным точкам в IIS, я вижу эти два отрывка:

"Предположим, у вас есть файл с именем calc.svc, и вы помещаете его в виртуальный каталог, который соответствует (http://localhost:8080/calcservice). Базовый адрес для этой службы будет (http://localhost:8080/calcservice/calc.svc)."

и

"Теперь рассмотрим конфигурацию конечной точки, найденную в файле web.config виртуального каталога (на рисунке 3). В этом случае адрес первой конечной точки становится таким же, как базовый адрес (http://localhost:8080/calcservice/calc.svc), поскольку я оставил адрес конечной точки пустым. Адрес второй конечной точки становится комбинацией базового адреса с добавлением «secure», например: (http://localhost:8080/calcservice/calc.svc/secure)."

Теперь в моем приложении я пытаюсь создать две конечные точки для одного и того же сервиса (показано ниже). Название сервиса MainService.svc. Для конечной точки один у меня есть address = "", а конечная точка два имеет address = "Soap11". Поднимая сайт в IIS, я могу успешно перейти по этому URL: (https://localhost:444/MainService.svc). Это базовый адрес для службы в соответствии со всей документацией, которую я могу найти. Согласно этой и другим статьям, которые я видел, которые подтверждают его информацию У меня должна быть вторая конечная точка в (https://localhost:444/MainService.svc/Soap11), но если я перейду к этому URL, я получу исключение .Net, указывающее, что ресурс не найден.

Есть ли инструмент, который я могу использовать для см. , где будут доступны мои разные конечные точки? Может быть, некоторые журналы IIS или aspnet_isapi.dll я могу включить? Мой раздел web.config, определяющий мои конечные точки, следует.

Заранее спасибо за помощь

<service behaviorConfiguration="MyService.MainServiceBehavior" name="MyService.MainService">
  <endpoint address="" binding="wsHttpBinding" bindingConfiguration="WSBindingConfig" contract="MyService.IMainService">
    <identity>
      <dns value="localhost" />
    </identity>
  </endpoint>
  <endpoint address="Soap11" binding="basicHttpBinding" bindingConfiguration="BasicBindingWithCredentials"
            contract="MyService.IMainService">
    <identity>
      <dns value="localhost" />
    </identity>
  </endpoint>
  <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>

Глядя дальше, я вижу, что WSDL ссылается на эти две конечные точки и в местах, где я ожидаю их найти. Я все еще испытываю трудности, используя их как бы то ни было. Вот что есть в сервисе:

<wsdl:service name="MainService">
    <wsdl:port name="WSHttpBinding_IMainService" binding="tns:WSHttpBinding_IMainService">
        <soap12:address location="https://localhost/MainService.svc/Soap12" /> 
        <wsa10:EndpointReference>
            <wsa10:Address>https://localhost/MainService.svc/Soap12</wsa10:Address> 
                <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
                <Dns>localhost</Dns> 
            </Identity>
        </wsa10:EndpointReference>
    </wsdl:port>
    <wsdl:port name="BasicHttpBinding_IMainService" binding="tns:BasicHttpBinding_IMainService">
        <soap:address location="https://localhost/MainService.svc/Soap11" /> 
    </wsdl:port>
</wsdl:service>

Попытка указать моему клиенту URL-адрес (https://localhost/MainService.svc/Soap11 или Soap12), однако, не работает. Я получаю «Внутренняя ошибка сервера 500» в качестве базового исключения с «Тип содержимого text / html; charset = utf-8 в ответном сообщении не соответствует типу содержимого привязки (application / soap + xml; charset = utf»). -8) "как крайнее исключение.

Answer 1

Я не уверен, что нашел ответ, но сомневаюсь, что здесь будет больше активности, поэтому помечать этот ответ не повредит. Вот что я нашел.

Конфигурация, которую я описал выше, по-видимому, правильная, но, хотя я не видел в Интернете никакой информации об этом, по-видимому, метаданные находятся по базовому адресу независимо от того, сколько конечных точек у вас есть для вашей службы. Создается впечатление, что вы должны использовать базовый адрес для генерации прокси-сервера для клиента, а затем переназначить свой код по адресу / Soap11 или / Soap12.

Я успешно смог отправить вызовы на Soap11 с помощью basicHttpBinding от клиента, но не смог успешно связаться с Soap12 с помощью wsHttpBinding, хотя я не думаю, что эта проблема связи связана с рассматриваемым вопросом.

Единственное, что я забронировал, это то, что должен быть способ указать один URL-адрес, чтобы и получить ваш WSDL, и отправить ваше сообщение, хотя с этим решением вы не сможете.