Как изменить URL-адрес WSDL с внутреннего имени машины на общедоступный?

У меня есть простой сервис, который я использовал для Azure. Доступ к нему осуществляется через:

http://xxxxxxxxxxxxxxxxxxxxxxx.cloudapp.net/MyTestService.svc

URL-адрес WSDL использует внутреннее имя машины вместо общедоступного DNS:

svcutil.exe http://rd001520d328923a/MyTestService.svc?wsdl

Очевидно, что WSDL недоступен извне машины с этим.

Мне известно о нескольких вещах, которые можно изменить, если вы используете это в IIS, или если вы знаете URL-адрес службы. Например, изменив конфигурацию <serviceMetadata>, чтобы указать свойство httpGetUrl, но это не сработает, поскольку мне нужно будет включить абсолютный URL. Используя относительный URL-адрес, он все еще использует внутреннее имя машины. Реальная проблема заключается в том, что WSDL содержит ссылки на URL с именем машины, что делает его бесполезным.

Существует два нестандартных метода:

Было высказано предположение, что я могу захватить WSDL, отредактировать его, чтобы исправить URL-адреса, а затем загрузить его, чтобы он был доступен с другого URL-адреса.
Я обнаружил, что исправление с начала 2010 года было доступно, но там должен быть лучший способ.

Как это можно решить, если вместо имени машины будет использоваться общедоступный DNS-сервер?

Ответ 1

Ok. Я смотрю на это почти неделю. Я, наконец, нашел ответ, так как он недоступен. Надеюсь, что это индексируется и сэкономит время для других.

В основном это общее поведение как известная проблема с WCF 3.0/3.5, для которой они выпустили исправление. Вы можете узнать больше здесь: ИСПРАВЛЕНИЕ: URI в документе WSDL WCF относятся к недоступным внутренним экземплярам, а не к балансировщику нагрузки...

Мне приходилось сталкиваться с этим несколько раз во время моего исследования, но не давало ему второй мысли, главным образом потому, что я понятия не имел, как развернуть исправление в Azure.

К счастью, модератор Microsoft на форумах MSDN указал, что это было исправлено в .net 4.0. Это означало, что исправление, рекомендованное в статье KB выше, все еще применяется, за исключением того, что исправление не должно применяться. Так в чем же решение? Просто добавьте в конфигурационный файл следующее:

<serviceBehaviors>
   <behavior name="<name>">
     <!-- Other options would go here -->
     <useRequestHeadersForMetadataAddress>
       <defaultPorts> <!-- Use your own port numbers -->
          <add scheme="http" port="81" />
          <add scheme="https" port="444" />
        </defaultPorts>
      </useRequestHeadersForMetadataAddress>
   </behavior>
</serviceBehaviors>

И все. Это был бы гораздо более простой поиск, если бы было ясно, что этот вопрос теперь исправлен. Возможно, я не выглядел достаточно тяжело.

Ответ 2

Сообщение в блоге Использование заголовков запросов для адреса метаданных похоже на
Victor answer, но объясняет, что порты по умолчанию являются необязательными и может быть опущен:

<system.serviceModel>
  <behaviors>
       <serviceBehaviors>
          <behavior>
            <useRequestHeadersForMetadataAddress/>
          </behavior>
        </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Он также показывает, как включить поведение в коде.

sh.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());

Ответ 3

Вы создаете WSDL, чтобы опубликовать его, или просто пытаетесь добавить ссылку в другой проект?

Если это позже, мое предложение - использовать подход WCF ChannelFactory, а не "добавить ссылку на службу". Я нахожу, что это дает мне более стабильные контролируемые результаты.

http://msdn.microsoft.com/en-us/library/ms734681.aspx

Я должен добавить, я не пробовал это на Azure.