How to change WSDL URL from internal machine name to public?

Question

I have a simple service that I deployed to Azure. It is accessible via:

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

The U

Answer 1

The blog post Using Request Headers for Metadata Address is similar to
Victor's answer, but explains that default ports are optional and can be omitted:

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

It also shows how to enable the behavior in the code.

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

Answer 2

Ok. I have been looking at this for almost a week. I finally found the answer, since it is not easily available I hope this gets indexed and save the time for others.

Basically this overall behavior as a known issue with WCF 3.0/3.5, for which they released a hotfix. You can find out more here: FIX: URIs in a WCF WSDL document refer to inaccessible internal instances instead of to the load balancer...

I had come across this a few times during my research but never gave it a 2nd thought, mostly because I had no idea how I would deploy a hotfix into Azure.

Fortunately, a Microsoft moderator at the MSDN forums pointed out that this had been fixed in .net 4.0. What this meant was that the "fix" recommended in the KB article above, still applied, with the exception that no hotfix had to be applied. So what is the solution? Simple, add the following to the config file:

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

And that was it. This would have been a much simpler search if it had been clearer that this issue had now been fixed. Perhaps I didnt look hard enough.

Answer 3

Are you generating the WSDL in order to publish it, or are you just trying to add a reference in another project?

If it's the later, my suggestion is to use the WCF ChannelFactory approach rather than "add service reference". I find it gives me more consistent controllable results.

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

I must add, I haven't tried this on Azure.