wcf - error - metadata publishing for this service is currently disabled

¿Cómo cambiar la URL WSDL del nombre interno de la máquina a público?

Question

Tengo un servicio simple que implementé en Azure. Se puede acceder a través de:

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

La URL del WSDL usa el nombre interno de la máquina en lugar de un DNS público:

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

Obviamente, el WSDL no es accesible desde fuera de la máquina con esto.

Soy consciente de algunas cosas que se pueden cambiar si está ejecutando esto en IIS o si conoce la url del servicio. Por ejemplo, cambiar la configuración <serviceMetadata> para especificar la propiedad httpGetUrl , pero esto no funcionará, ya que tendría que incluir la URL absoluta. Al usar una URL relativa, todavía usa el nombre interno de la máquina. El verdadero problema es que el WSDL incluye referencias de URL con el nombre de la máquina, por lo tanto, es inútil.

Hay dos soluciones estándar deficientes:

• Se ha sugerido que podría tomar el WSDL, editarlo para corregir las URL y luego subirlo para que sea accesible desde una URL diferente.

• Encontré una revisión de principios de 2010 disponible, pero tiene que haber una forma mejor.

¿Cómo se puede resolver esto para que se use el DNS frente al público en lugar del nombre de la máquina?

Answer 1

¿Está generando el WSDL para publicarlo, o simplemente está tratando de agregar una referencia en otro proyecto?

Si es el último, mi sugerencia es utilizar el enfoque WCF ChannelFactory en lugar de "agregar referencia de servicio". Encuentro que me da resultados controlables más consistentes.

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

Debo agregar, no he probado esto en Azure.

Answer 2

De acuerdo. He estado mirando esto por casi una semana. Finalmente encontré la respuesta, ya que no está disponible fácilmente, espero que esto se indexe y ahorre tiempo para otros.

Básicamente este comportamiento general como un problema conocido con WCF 3.0 / 3.5, para el cual lanzaron una revisión. Puede encontrar más información aquí: REVISIÓN: los URI en un documento WCF WSDL se refieren a instancias internas inaccesibles en lugar de al equilibrador de carga ...

Me había topado con esto varias veces durante mi investigación, pero nunca lo pensé dos veces, sobre todo porque no tenía idea de cómo implementaría una revisión en Azure.

Afortunadamente, un moderador de Microsoft en los foros de MSDN señaló que esto se había solucionado en .NET 4.0. Lo que esto significaba era que la "corrección" recomendada en el artículo de KB anterior, todavía se aplicaba, con la excepción de que no se debía aplicar ningún hotfix. ¿Entonces, cuál es la solución? Simple, agregue lo siguiente al archivo de configuración:

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

Y eso fue todo. Esta habría sido una búsqueda mucho más simple si hubiera sido más claro que este problema ya se había solucionado. Tal vez no parecía lo suficientemente duro.

Answer 3

La publicación del blog Uso de encabezados de solicitud para la dirección de metadatos es similar a
La answer , pero explica que los puertos predeterminados son opcionales y pueden omitirse:

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

También muestra cómo habilitar el comportamiento en el código.

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