locked
There was no endpoint listening error RRS feed

  • Question

  • I moed my WCF service from VS hosted to IIS - so it's now at new address. I regenerated my configs and it is working for a basic web service but my custom end point for large file uploads has stopped working with the following error:

    There was no endpoint listening at http://spdev.winsmarts.internal:9000/DocumentManager.svc/test that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

     Also when I look in the inner exception I see file not found

    There is no error in the log

     WS Config
    
    
    
      <basicHttpBinding>
    
      <binding name="httpLargeFileBinding" maxBufferSize="655360000"
    
       maxReceivedMessageSize="655360000">
    
       <readerQuotas maxDepth="655360000" maxStringContentLength="655360000" maxArrayLength="655360000"
    
       maxBytesPerRead="655360000" maxNameTableCharCount="655360000"></readerQuotas>
    
       </binding>
    
      </basicHttpBinding>
    
    
    
    
    
      <service behaviorConfiguration="httpLargeFileBehaviour" name="PurchaseOrderWebService.DocumentManager">
    
      <endpoint address="/test"
    
       binding="basicHttpBinding" bindingConfiguration="httpLargeFileBinding"
    
       name="largeFileEndPoint" bindingName="httpLargeFileBinding"
    
       contract="PurchaseOrderWebService.IDocumentManager" />
    
      <endpoint binding="mexHttpBinding" bindingConfiguration="" name="mex"
    
       contract="IMetadataExchange" />
    
      <host>
    
       <baseAddresses>
    
       <add baseAddress="http://sharepointdev.winsmarts.internal:9000/DocumentManager.svc" />
    
       </baseAddresses>
    
      </host>
    
      </service>
    
    
    
    Client Config
    
    
    
       <endpoint address="http://sharepointdev.winsmarts.internal:9000/DocumentManager.svc/test"
    
        binding="basicHttpBinding" bindingConfiguration="largeFileEndPoint"
    
        contract="DocumentManagerWS.IDocumentManager" name="largeFileEndPoint" />
    
    

    I call my web service like this:

      public string CreatePurchaseOrder(CompoundLocalBLL.Doc LocalObject)
    
      {
    
       var ws = new DocumentManagerWS.DocumentManagerClient("largeFileEndPoint");
    
       var DTO = new DocDTO();
    
       var Doc = new Doc();
    
       Doc = MapLocalObjectToServerObject(LocalObject);
    
       Doc.StatusID = 1;
    
       Doc.DocTypeID = 1;
    
       DTO = MapObjectToDTO(Doc);
    
       return ws.InsertPurchaseOrder(DTO);
    
    
    
      }

    Chris
    Wednesday, March 23, 2011 7:21 PM

Answers

All replies

  • if you use the wcf test client or create a new client from the new wsdl address do you still get the error?
    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Wednesday, March 23, 2011 9:00 PM
  • Yes I do get responses using the WCF web client but that I think is going to the general endpoint i.e.

    DocumentMeanager.svc

    not the custom endpoint I have created for large file uploads:

    DocumentMeanager.svc/test

    I'm really not sure I'm doing it right. Cheers.


    Chris

    Thursday, March 24, 2011 12:37 PM
  • Hello, try to enable tracing as described on http://msdn.microsoft.com/en-us/library/ms733025.aspx. You may find out more information. Also check if you have something (such as ASP.NET URL Routing) that may affect the URI.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Windows Azure Technical Forum Support Team Blog
    • Marked as answer by Fresno Bob Friday, March 25, 2011 10:02 AM
    Friday, March 25, 2011 1:55 AM
  • I turned out to be uploading too many files. I was uploading a list of byte arrays which are files. I was uploading 20 instead of 1. Confusing error though. What is the best way to upload large volumes of data via WCF. The trace just gave a 404 error. Not sure if I fixed 2 problems instead of one.
    Chris
    Friday, March 25, 2011 11:06 AM