none
There was no endpoint listening at....

    Question

  • 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" />
       </service>

     

    Could it have something to do with the 'mex' thing? (I never really understood what that is...)
    Wednesday, May 9, 2007 7:09 PM

Answers

  • 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

    Thanks

    Wednesday, May 9, 2007 9:08 PM
  •  

    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

    Friday, May 11, 2007 2:14 PM

All replies

  • 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

    Thanks

    Wednesday, May 9, 2007 9:08 PM
  • 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:

    MessageBox.Show(myService.Endpoint.Address.ToString());

    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

    Thursday, May 10, 2007 5:55 AM
  • 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)?

    Thursday, May 10, 2007 6:33 AM
  • Accessing https://server.myDomain.se/MyVirtualDir/SensorService.svc?wsdl

    Gives this address information towards the end of the XML:

    <soap12:address location=https://server.myDomain.se/MyVirtualDir/SensorService.svc />

    - <wsa10:EndpointReference>
      <wsa10:Address>https://server.myDomain.se/MyVirtualDir/SensorService.svc</wsa10:Address>
      </wsa10:EndpointReference>

     

    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

    https://server.myDomain.se/MyVirtualDir/SensorService.svc/mex

    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

    Thursday, May 10, 2007 7:18 AM
  • Aha.  Note that the svcutil-generated client thinks the address is

    https://server.mydomain.se/MyVirtualDir/SensorService.svc

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

    https://myserver/VirtualDir/MyService.svc

    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.

    Thursday, May 10, 2007 1:28 PM
  • 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" />
       </service>

     

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

     

    Regards Andreas

    Thursday, May 10, 2007 2:00 PM
  • 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.)

    Thursday, May 10, 2007 2:12 PM
  • Here is my custom binding:

    <customBinding>
        <binding name="MyBinding">
         <transactionFlow />
         <security authenticationMode="SecureConversation">
          <secureConversationBootstrap authenticationMode="UserNameOverTransport" >
           <localServiceSettings maxClockSkew="00:15:00" />
          </secureConversationBootstrap>
          <localServiceSettings maxClockSkew="00:15:00" />
         </security>
         <httpsTransport />
        </binding>
       </customBinding>

     

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

     

    Regards Andreas

    Thursday, May 10, 2007 2:51 PM
  • 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

    Friday, May 11, 2007 6:44 AM
  • 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

    Friday, May 11, 2007 8:03 AM
  •  

    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

    Friday, May 11, 2007 2:14 PM
  • This post is similar to this one. So... if you still have this issue try to follow this thread:

     

    http://forums.microsoft.com/msdn/ShowPost.aspx?postid=3172599&isthread=false&siteid=1

     

    A way i found to solve this issue (after no answer heh) is to update the entire operating system (both critical and non critical updates) on everything related to .Net Framework 3.0 as well as security and O.S. updates. It seems to be inside a windows fix (not inside FW3.0 nor it's service pack), because the internet explorer answered well at wsdl. It seems to be a little exceptions (because here, one of each... 50 computers presents this issue). So... if none of the above solved your issue, consider to keep the issued PC the most up to date as possible.

     

     

    Hope it helps

     

    Rick.

    MCPD - EA

    MCITP - DD




    RGONZALEZP

    Monday, April 14, 2008 2:22 PM
  • Hi All,

     

    By Using msyoun app.config example as below you can solve this problem by adding the Service Endpoint Address from your service to the config file. Refer to the bold font below. Blue font is the Service Endpoint address name. I solve my problem by using this method. Hope can help you all..

     

    ******************************************************************************************************************* 

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <system.serviceModel>
            <bindings>
                <basicHttpBinding>
                    <binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
                        openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                        allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                        maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                        messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                        useDefaultWebProxy="true">
                        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                            maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                        <security mode="None">
                            <transport clientCredentialType="None" proxyCredentialType="None"
                                realm="" />
                            <message clientCredentialType="UserName" algorithmSuite="Default" />
                        </security>
                    </binding>
                </basicHttpBinding>
                <wsHttpBinding>
                    <binding name="WSHttpBinding_IService1" closeTimeout="00:01:00"
                        openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                        bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                        maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                        messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                        allowCookies="false">
                        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                            maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                        <reliableSession ordered="true" inactivityTimeout="00:10:00"
                            enabled="false" />
                        <security mode="Message">
                            <transport clientCredentialType="Windows" proxyCredentialType="None"
                                realm="" />
                            <message clientCredentialType="Windows" negotiateServiceCredential="true"
                                algorithmSuite="Default" establishSecurityContext="true" />
                        </security>
                    </binding>
                </wsHttpBinding>
            </bindings>
            <client>
                <endpoint address="http://THEMACHINENAME.THEDOMAIN.com/endpointTest/service.svc"
                    binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IService1"
                    contract="WebClient.webservice.IService1" name="WSHttpBinding_IService1">
                    <identity>
                        <userPrincipalName value="THEMACHINENAME\ASPNET" />
                    </identity>
                </endpoint>
                <endpoint address="http://THEMACHINENAME.THEDOMAIN.com/endpointTest/service.svc/basic"
                    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService1"
                    contract="WebClient.webservice.IService1" name="BasicHttpBinding_IService1" />
            </client>
        </system.serviceModel>
    </configuration>


     

    Monday, July 7, 2008 4:36 AM
  • Hi Andreas,

    I have the same problem. How can check if my firewall is redirecting traffic on port 80 to port 443 and remove the rule?

    Cheers,

    Chuy 

    Monday, September 5, 2011 10:01 PM
  • I had the same error, and when I enabled the tracing on IIS and reviewed the trace with SvcTraceViewer.exe, the actual internal error was "Maximum request length exceeded." 

    My client was uploading an image via the service. And I guess the image was too big.

    To enable tracing I added this to the <configuration> section:

    <system.diagnostics>
          <sources>
                <source name="System.ServiceModel" 
                        switchValue="All"
                        propagateActivity="true">
                <listeners>
                   <add name="traceListener" 
                       type="System.Diagnostics.XmlWriterTraceListener" 
                       initializeData= "c:\log\Traces.svclog" />
                </listeners>
             </source>
          </sources>
       </system.diagnostics>

    To solve the error, I increased the message request length in the web config and the error went away.

    To do this, in the <system.web> section in the web.config I added the line:

    <httpRuntime maxRequestLength="32768" />

    Then I added this section inside the <configuration> section

    <system.webServer>
       <security>
          <requestFiltering>
             <requestLimits maxAllowedContentLength="32000000" />
          </requestFiltering>
       </security>
     </system.webServer>

    Friday, April 4, 2014 5:07 PM
  • Hi How can I check this settings of Firewall??

    Thanks

    Shanu

    Tuesday, July 22, 2014 7:13 AM