locked
WCF service on Azure: 'The remote name could not be resolved'. The WCF service works OK on local machine. The remote name is unknown an address to me. RRS feed

  • Question

  • I have a WCF service that works fine on my local machine, but when I deploy it to Azure and do an Invoke with wcftest I get the message

    Failed to invoke the service. Possible causes: The service is offline or inaccessible; the client-side configuration does not match the proxy; the existing proxy is invalid. Refer to the stack trace for more detail. You can try to recover by starting a new proxy, restoring to default configuration, or refreshing the service.

    There was no endpoint listening at http://rd00155d3ad8c4/GeneralApplicationServices.svc/AppActivity that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

    Inner Exception:
    The remote name could not be resolved: 'rd00155d3ad8c4'
       at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
       at System.Net.HttpWebRequest.GetRequestStream()
       at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.GetOutputStream()

    The strange thing is that I don't know where rd00155d3ad8c4 is coming from in the URI. It should be something like http://mysite.cloudapp.net. I've searched the entire solution for this strange string, but no luck.

    The service seems to be exposed correctly at http://mysite.cloudapp.net/GeneralApplicationServices.svc

    I've really no clue were to look anymore.


    • Edited by Richard D Monday, May 7, 2012 3:51 PM
    Monday, May 7, 2012 3:41 PM

Answers

  • Hello, have you added the useRequestHeadersForMetadataAddress behavior to the service as described on http://support.microsoft.com/kb/971842? You don't need to install the hotfix if you're using .NET 4 (it has been fixed in .NET 4), but this behavior is required for WSDL to work properly in load balanced environments like Windows Azure.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    If you have feedback about forum business, please contact msdnmg@microsoft.com. But please do not ask technical questions in the email.

    • Marked as answer by Richard D Tuesday, May 8, 2012 6:41 AM
    Tuesday, May 8, 2012 1:50 AM

All replies

  • Well any config files and service reference files on the client-side
    should be searched for the string in question and changed to the correct
    setting to find the site.
     
    Monday, May 7, 2012 5:15 PM
  • Hi darnold92,

    Thanks for you reply.

    I've did a full disk search for rd00155d3ad8c4 on my development PC, but there is no string in any file that resembles rd00155d3ad8c4 :-(

    Monday, May 7, 2012 5:54 PM
  • On 5/7/2012 1:54 PM, Richard Driessen wrote:
    > Hi darnold92,
    >
    > Thanks for you reply.
    >
    > I've did a full disk search for rd00155d3ad8c4 on my development PC, but
    > there is no string in any file that resembles rd00155d3ad8c4 :-(
    >
     
    I suggest that you edit the service Reference files on the client-side
    and look, because that's the only time I have seen the condition your
    are posting about that was in those files. What's in the config file
    should override what the service reference files are pointing to, and
    sometimes it doesn't happen. That string is somewhere in the solution I
    suspect, and it just doesn't happen by itself that it comes-up with some
    dubious site address.
     
    Monday, May 7, 2012 9:07 PM
  • Hello, have you added the useRequestHeadersForMetadataAddress behavior to the service as described on http://support.microsoft.com/kb/971842? You don't need to install the hotfix if you're using .NET 4 (it has been fixed in .NET 4), but this behavior is required for WSDL to work properly in load balanced environments like Windows Azure.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    If you have feedback about forum business, please contact msdnmg@microsoft.com. But please do not ask technical questions in the email.

    • Marked as answer by Richard D Tuesday, May 8, 2012 6:41 AM
    Tuesday, May 8, 2012 1:50 AM
  • Hi Yi-Kun Luo,

    You really made my day !! Everythings works fine now. I've been searching on this subject for three days, so your info was most welcome. Yesterday I came across the kb article you mentioned, but I trought is wasn't applicable anymore. So thats the second lesson learned.

    Thanks againg.

    Richard.

    Tuesday, May 8, 2012 6:43 AM
  • Yi-Lun Luo

    I would also like to express my profound thanks. I've spent over a day chasing my own tail on this. Such a relief. 

    Thursday, January 9, 2014 9:01 AM