Tags: dev-server, endpoint, listening, microsoft, moved, msdn, production, server, service, software, studio, visual, wcf

There was no endpoint listening at....

On Microsoft » Microsoft Visual Studio

13,379 words with 11 Comments; publish: Thu, 03 Jan 2008 07:41:00 GMT; (300140.63, « »)

I just moved my WCF service from a dev-server to a production server. On the dev-server everything works fine, but on the production server I'm getting the error:

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

I can brows to https://MyServer/MyVirtualDir/MyService.svc and https://MyServer/MyVirtualDir/MyService.svc?wsdl recieving expected results, but the when trying to call a method on the service I get the error...

I also checked that the .svc extension is registered on the virtual directory in ISS.

Here is the service tag from my web.config file:

<service name="MyService.Services.GeneralService" behaviorConfiguration="AspNetRolesBehavior">

<endpoint address="https://MyServer/VirtualDir/MyService.svc" binding="customBinding" bindingConfiguration="MyBinding" contract="MyService.Services.IGeneralService" />

<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />


Could it have something to do with the 'mex' thing? (I never really understood what that is...)

All Comments

Leave a comment...

    • Hi,

      Most of the times that error means that either you are not making the request to the right URI or the service is not just started listening.

      Please check the URI being used by the client and server. It is good idea to print out (or log it to a file) from both and server sides so that you can verify what is being used at runtime.

      Also, check the eventlogs for any errors reported by IIS/Asp.Net


      #1; Thu, 13 Sep 2007 17:40:00 GMT
    • I have tried do double check the URI a couple of times and it should be the same on both ends. Doing the following from the client:


      Prints the same address that's logged in the .svclog when the error is thrown. However, it seems like the service is never started, since my logging attempts from service host constructor is never executed. Have I missed some IIS / WCF configuration?

      Could an incompatible SSL-certificate cause this problem?

      Regards Andreas

      #2; Thu, 13 Sep 2007 17:41:00 GMT
    • I think it is not unexpected that your Service class's constructor is not getting called, it would only be called when the first application message arrives, and that doesn't seem to be happening (the problem).

      When you look at the wsdl on the production server (by browsing the .svc?wsdl), what hostname does it show as the address? Does it match the expected value?

      What happens if you try to hit the production service svc with svcutil.exe (either at the base address, or at the 'mex' address)?

      #3; Thu, 13 Sep 2007 17:42:00 GMT

Running "svcutil.exe https://server.myDomain.se/MyVirtualDir/SensorService.svc" gives this information in output.config:

<endpoint address=https://server.myDomain.se/MyVirtualDir/SensorService.svc

binding="wsHttpBinding" bindingConfiguration="CustomBinding_ISensorService"

contract="ISensorService" name="CustomBinding_ISensorService" />

And sensorservice.cs is created correctly (stub-methods and classes are generated as expected)

This is the client error-message:

There was no endpoint listening at https://server.myDomain.se/MyVirtualDir/SensorService.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

In the .svclog file, there are two errors. First one that says this:

Failed to lookup a channel to receive an incoming message. Either the endpoint or the SOAP action was not found.

And then one with the exact same message that is sent back to the client (see above).

Does it have something to do with the mex-thing? Because browsing to


gives the following error:

Internet Explorer cannot download mex from server.myDomain.se.

Internet Explorer was not able to open this Internet site.

The requested site is either unavailable or cannot be found.

Please try again later.

Perhaps it is of interest that the production machine (where this happens) runs Windows 2003 server Standard x64 and the dev server where it works runs Windows 2003 server Professional (x32).Could that have something to do with anything?

Your help is very appreciated!

Regards Andreas

#4; Thu, 13 Sep 2007 17:43:00 GMT
    • Aha. Note that the svcutil-generated client thinks the address is


      whereas according to your original post, the server's web config thinks the address is


      In any case, the answer is that you should change the address in the server's web.config file to "" (the empty string). The absolute Uri value in the config file is brittle - you should use relative addresses in the config file, and this makes it possible to, say, move the service from dev to production and even if the production app is hosted in different location/environment, things will still work.

      #5; Thu, 13 Sep 2007 17:44:00 GMT
    • Well, sorry to say, but the first message is a bit missleading here. I just changed it to https://myserver/VirtualDir/MyService.svc, since I didn't want to post my domain... But the real value for the endpoint address was "https://server.mydomain.se/MyVirtualDir/SensorService.svc" and now I have also tried changing it to "", so now it looks like this:

      <service name="MyNamespace.Services.SensorService" behaviorConfiguration="AspNetRolesBehavior">

      <endpoint address="" binding="customBinding" bindingConfiguration="MyBinding" contract="MyNamespace.Services.ISensorService" />

      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />


      But the result if I redo the test is exactly the same... =(

      Regards Andreas

      #6; Thu, 13 Sep 2007 17:45:00 GMT
    • Bummer, I really thought that was it.

      This error message

      Failed to lookup a channel to receive an incoming message. Either the endpoint or the SOAP action was not found.

      seems to indicate that a request arrived at this WCF IIS-hosted service, but there is no endpoint listening at that address.

      Can you share your 'customBinding'? Have you set the hostnameComparisonMode on the transport, perchance?

      (You can try commenting out the 'mex' endpoint, if you are still concerned about it, but I don't think that's the problem.)

      #7; Thu, 13 Sep 2007 17:46:00 GMT
    • Here is my custom binding:


      <binding name="MyBinding">

      <transactionFlow />

      <security authenticationMode="SecureConversation">

      <secureConversationBootstrap authenticationMode="UserNameOverTransport" >

      <localServiceSettings maxClockSkew="00:15:00" />


      <localServiceSettings maxClockSkew="00:15:00" />


      <httpsTransport />



      And I tried to comment out the mex endpoint, but with no change in luck...

      Regards Andreas

      #8; Thu, 13 Sep 2007 17:47:00 GMT
    • I should add to the information that the production server is located on a server-hotel, behind firewalls. But ports for web/ssl should be open. Could it have something to do with this anyway?

      Can I have forgotten some setting that makes IIS don't wanna start the service upon calls to it?

      Regards Andreas

      #9; Thu, 13 Sep 2007 17:48:00 GMT
    • I have now tested running the client application on the local network where the production server is located and that works fine. But not from remote. So, I guess it has something to do with the firewall... Witch port should be open in order for WCF to talk http over ssl... (see binding above)?

      Regards Andreas

      #10; Thu, 13 Sep 2007 17:49:00 GMT
    • Problem solved!

      It showed up that the firewall was configured to route all traffic on port 80 to port 443, when that rule was removed it started working!

      Thanks for your time!

      Regards Andreas

      #11; Thu, 13 Sep 2007 17:50:00 GMT