wcf - 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 URL to the WSDL uses the internal machine name instead of a public DNS:

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

Obviously, the WSDL is not accessible from outside the machine with this.

I am aware of a few things that can be changed if you are running this in IIS, or if you do know the url of the service. For example changing the <serviceMetadata> config to specify the httpGetUrl property, but this will not work as I would have to include the absolute URL. Using a relative URL, it still uses the internal machine name. The real issue is that the WSDL includes URL references with the machine name, therefore rendering it useless.

There are two substandard workarounds:

• It has been suggested that I could grab the WSDL, edit it to fix the URLs and then upload it so it is accessible from a different URL.

• I found a hotfix from early 2010 was available, but there's got to be a better way.

How can this be solved to have the public facing DNS used instead of the machine name?

question from:https://stackoverflow.com/questions/5007270/how-to-change-wsdl-url-from-internal-machine-name-to-public

Answer 1

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.