tags:

views:

3850

answers:

1

I am trying to debug a WCF service. This client has been able to connect in the past, but now I cannot connect. The service is deployed to a server. I can hit the server's service page with the browser and I see the instructions for generating a client. I re-generated the client proxy and configuration file using svcutil.

The client starts up, but the first call to the service returns with an error after the 1 minute timeout. Meanwhile, I can attach to the service running on the server and step through the code there. I can see that my client was never registered. A breakpoint in the server code for this call does not get hit. For some reason, I cannot step into the server code (but I can attach the debugger to the service on the server):

Unable to automatically step into the server. 
Connecting to the server machine 'shuttle' failed. 
Please install the Visual Studio 2008 Remote Debugger on the 
server to enable this functionality.

The remote debugger is installed and running, or course. I am getting this error after a long timeout:

Client is unable to finish the security negotiation within the 
configured timeout (00:00:00).  The current negotiation leg is 1 (00:00:00).

When I set security mode=none, and increase the timeout, the error changes to

The open operation did not complete within the allotted timeout of 00:02:00.
The time allotted to this operation may have been a portion of a 
longer timeout.

I don't have any firewalls running and I see the request coming in on the server in Ethereal. I am looking at the TCP stream and I cannot say why the negotiation is failing. There is nothing related in the event log. I am running out of steam and would appreciate a hint.

The client app.config contains the section that svcutil generated:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <wsDualHttpBinding>
                <binding name="WSDualHttpBinding_SportRadarDCS" 
                    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">
                      <readerQuotas 
                       maxDepth="32" maxStringContentLength="8192"  
                       maxArrayLength="16384"
                       maxBytesPerRead="4096" 
                       maxNameTableCharCount="16384" />
                    <reliableSession ordered="true" 
                       inactivityTimeout="00:10:00" />
                    <security mode="Message">
                        <message clientCredentialType="Windows" 
                           negotiateServiceCredential="true"
                           algorithmSuite="Default" />
                    </security>
                </binding>
            </wsDualHttpBinding>
        </bindings>
        <client>
            <endpoint
                 address="...."
                binding="wsDualHttpBinding" 
                    bindingConfiguration="WSDualHttpBinding_SportRadarDCS"
                    contract="SportRadarDCS" 
                    name="WSDualHttpBinding_SportRadarDCS">
                <identity>
                    <userPrincipalName value=".. my domain user ..." />
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>
</configuration>
+5  A: 

Have a look at WCF Tracing. If you run this on your service host, it will give you individual WCF calls which are occuring, and should be enough for you to find out what part of your configuration is pooched.

I found specifically with connection issues that this was the only way to troubleshoot the reasons.

MSDN on WCF Tracing your application

A good tutorial to help you understand the MSDN

Spence
Thanks, very helpful. The error that I found is: There was no channel that could accept the message with action 'http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence'. I will take if from here.
cdonner
And it turns out that this was a DNS issue. My workstation for some reason was not in the DNS and the lookup on the server for the callback endpoint failed. Once I had fixed that, it worked.
cdonner
cheers for proving the point, troubleshoot the connection issue via WCF tracing. Glad you fixed your issue.
Spence