Как изменить URL WSDL с внутреннего имени машины на публичное?

Question

У меня есть простой сервис, который я развернул в 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 вместо имени компьютера?

Answer 1

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

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

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

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

<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>

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

Answer 2

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

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

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

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

Answer 3

Вы генерируете WSDL для его публикации или просто пытаетесь добавить ссылку в другой проект?

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

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

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