it-swarm-ru.tech

Как изменить 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 вместо имени компьютера?

39
Victor

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

В основном это общее поведение как известная проблема с 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>

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

64
Victor

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

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

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

sh.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());
22
Michael Freidgeim

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

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

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

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

0
Doobi