soap client working from console app, timeout when called from within wcf service

Question

here is the deal: I have a class library that makes calls to a web service via a soap client. When called from within a console application it works fine. When called from within a WCF service which is invoked by an http call I get an "EndpointNotFoundException - There was no endpoint listening at http://blablabla.asmx that could accept the message. This is often caused by an incorrect address or SOAP action..."

both app.config and web.config contain the exact same configuration for the client endpoint

so, whats going on? by the way, the WCF is running locally from Visual Studio. The soap web service I am trying to call is located on the internet.

this is how the service model configuration looks like. Its using basic authentication and the user and password are being set in code in the class library:

<system.serviceModel>
<bindings>
  <basicHttpBinding>
    <binding name="VocalServerSoap">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Basic" />
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
<client>
  <endpoint address="http://pseudourl.asmx"
    binding="basicHttpBinding" bindingConfiguration="VocalServerSoap"
    contract="VocalWebService.VocalServerSoap" name="VocalServerSoap" />
</client>

architecture

Without seeing code or config files it's very difficult to give any sort of coherent answer. I would start by comparing the app.config of the console application to the app/web.config of the WCF service, as well as the code that calls the legacy ASMX service in the console app to the code that calls the legacy ASMX service in the WCF service. Since the console application works and the WCF service doesn't, chances are the issue is in the code or the config file of the WCF service. — Tim, Oct 06 '13 at 19:55
As I stated the configurations are identical (copy paste). And the calling code is also identical since the asmx is being called from a class library. The same class library is being used in both projects... so no difference in code or configuration — aviv, Oct 07 '13 at 06:05
anyway - I edited the question to include the service model configuration — aviv, Oct 07 '13 at 06:11
I'd suggest peeking at your traffic, the simplest way to do that would be to run Wireshark, with a little more setup (you'd have to route your traffic through a proxy) you could use a proxy like Fiddler to have a better HTTP traffic parsing. — argaz, Oct 07 '13 at 07:49
good idea @argaz. inspecting the requests in fiddler shows that the cnosole app is sending basic authentication as its supposed to according to the configuration I set up, the WCF on contrary is trying Negotiate instead... but why should it? the configuration states basic authentication — aviv, Oct 07 '13 at 08:28
clarification - when debugging locally the behavior was unstable, sometimes I got timeout (due to no permissions) and sometimes it ran with the wrong authentication and sometimes it worked... I guess the difference was when using IIS express to run the local web or the visual studio development server — aviv, Oct 07 '13 at 11:52

score 3 · Accepted Answer · answered Oct 09 '13 at 18:47

ohhhh.... the frustration! After I thought I had it nailed down as a permissions problem (as per my prior post) it reverted to the same behavior of timing out.

Eventually its all because of the proxy.... it turns out that (from msdn):

Applications running as an NT Service or as part of ASP.NET use the Internet Explorer proxy server settings (if available) of the invoking user. These settings may not be available for all service applications.

so my requests to the soap service invoked from within the WCF service did not have a proxy configured at all... hence the no end point exception.

To overcome this I had to declare manually the proxy in the soap client binding:

<binding name="VocalServerSoap" proxyAddress="http://<your proxy address>:<proxy port>"
      useDefaultWebProxy="false">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Basic" />
      </security>
    </binding>

So why did I think it was permissions? How come it was working from time to time? Well, Fiddler had caused me a real confusion.... when activating fiddler everything worked since all outgoing requests where being routed to the proxy correctly because fiddler was using the system proxy.

I can not believe this wasted almost a day of my life :(

score 2 · Answer 2 · edited May 23 '17 at 12:30

2

update: this turned out not to be the problem. see my next post for clarifications

Nailed it down thanks to help from this post The problem was permissions - the application pool identity that ran the code from the WCF scope did not have permissions for internet access. Once i ran the web (change identity in IIS) site under a user that has permissions it worked.

edited May 23 '17 at 12:30

Community

1
1

answered Oct 07 '13 at 11:49

aviv

1,673
1
13
16

soap client working from console app, timeout when called from within wcf service

2 Answers2