SoapFaultException when invoking Myservice, saying “contract and binding mismatch between sender and receiver"?
above is my problem,
i have created WCF services and tested in Local(.net it is working fine.so hosted in Remote server. my client is using Java, when ever he is accessing the Wcf services ,he is getting error like" SoapFaultException saying “contract and binding mismatch between sender and receiver"
help me.
Thanks in advance
This sometimes happens if you are trying to call an old instance of your service with a proxy created for a new instance of your service. Or vice-versa.
If you are 100% sure that the service you are calling has the new method installed and running, then you should be able to diagnose this further by turning on tracing on the service.
Here is what I suggest, which I also suggested in another post:
Enable tracing on the service side and the client side, generate tracing logs, and analyze with SvcTraceViewer. To do this, follow the instructions at this MSDN article on using the service trace viewer.
Turn on debug exceptions. This is done by turning in includeExceptionDetailInFaults, which you can do by following the instructions here.
Use Fiddler to monitor the wire traffic on both the client side and the service side.
Generally, once you do this, you should plenty of more info on what's going funky at the service side and can diagnose the issue pretty quickly. Try it, and please report back! :)
Related
Ok, can I vent?? I am so sick and tired of this. I'm working away most of the day and the WCF services are working great. Next time I run my app and make a WCF call, bam! the tcp socket is no longer available. I have searched high and low to solve this and there is no real solution. The only solution I can find is to reboot the machine which is a huge time-waste and burden. Restarting WPA service, net.tcp service, IIS, etc. does not do a thing. Logging off and back on does not fix it. Only a reboot fixes this issue. I do nothing except run my app again making a WCF call, and this crap happens. There are no configuration issues with anything. I have been dealing with this for months and cannot find any specific reason or solution as to why this happens. It happens with my firewall on or off, does not matter.
Any insight from anyone? I think there is truly a bug in the WCF / net.tcp layer that is causing this. I even get it on a production 2008 R2 server when sometimes making a Web.config change, so I have learned to stop the IIS, WPA, net.tcp, etc. services prior to the change then restart them. What a pain.
I'm using .NET4 all around, VS2010, all service packs, etc. applied. Everything is the most current.
Excuse me while I reboot.....
Can anyone help with this?
Open a command prompt
Navigate to c:\windows\microsoft.net\framework64\v4.0.30319
Register the service model using the command "ServiceModelReg.exe -r"
Credits go there http://kumaranbose.blogspot.be/2010/08/cryptic-wcf-nettcp-errors.html
This issue hunts me for almost 3 years now but only happens sporadically. TCPView helped.
I have killed SMSSvcHost.exe process and then restarted Net.Tcp Listener Adapter service. That cleared the issue. Not really a solution but at least, I don't have to resort to rebooting the server anymore.
I had this issue. It would happen after each IIS reset (which happens as part of our deployment). The issue was resolved after restarting NetTcpPortSharing service (which also restarts Net.Tcp Listener Adapter service)
I am not sure I have an answer but, you could identify the process that has the port open and that can help narrow the scope of the problem. I have used Sysinternals suite which has a TCPView. This proggy was helpful to me.
TCPView - http://technet.microsoft.com/en-us/sysinternals/bb897437
Sounds Net.Tcp Listener Adapter service is being killed by some process or exception being throw by the web service putting the channel in a faulted state.
Have you tried setting the startup type of the service to automatic and recovery to restart service on first and second failure?
I doubt it very much that there is a bug in wcf net.tcp channel layer. If the listener is running and tcp socket no longer available i would suggest you look into the code especially around the exception handling strategy and have a peek into the iis request logs.
This may be a shot in the dark (I don't know much about the internals of WCF), but here goes...
I'm currently working with a legacy application at a client site and we're experiencing a persistent issue with a WCF service. The application is using the Microsoft Sync Framework 2.0 and syncing through the aforementioned service. The server-side implementation of the service has a lot of custom code in various states of "a mess."
Anyway, we're seeing an error on the client application most of the time and the pattern we're narrowing down centers around different users using the application on the same machine hitting the same service. It seems that the service and the client are getting out of sync in some way on an authentication level.
The error is discussed in an article here, and we're currently investigating the approach of switching from message layer security to transport layer security, which will hopefully solve the problem. However, we may be able to solve it in a less invasive manner if this question makes sense.
In the linked article, one of the suggestions was to forcibly terminate the connection if the specific exception is caught, try again, and if it fails again it wasn't because of this particular theory. Sounds good, and easy to implement. However, I find myself unable to say with confidence if the connection is being properly terminated.
The service operates through a custom interface, which is implemented on the server-side. The only thing that interface can do to end the connection is call EndSession() on the proxy itself, which calls EndSession() on the server which is a custom method.
So...
From a WCF service method, is there a way to properly and gracefully terminate the connection with the client in a way the client will like?
That is, in this custom EndSession() is there some last step I can take to cause the server to completely forget that this connection was open? Because it seems like when another user on the same machine tries to hit the service within the application, that's when it fails with the error in the linked article.
The idea is that, at the client side of things, code which calls EndSession() is followed by nulling out the proxy object, then a factory method is called to supply another one the next time it's needed. So I wonder if something additional needs to happen on the server side (and does by default in WCF were it not for all this custom implementation code) to terminate the connection on that end?
Like I said, a shot in the dark. But maybe in answers/discussions here I can at least further diagnose the problem, so any help is much appreciated. Thanks.
Unfortunately there are only really three ways in which a session can terminated
The client closes the proxy
The service's receiveTimeout is exceeded
before the client sends another
request
the service throws a
non-fault exception which will fault
the channel and so terminate the
session
if you don't want the client involved then you only have 2 and 3 neither of which end well for the client - they will get an exception in both situation on the next attempt to talk to the service.
You could use Duplex messaging and get the service to notify the client that its requires session termination - the client then gets an opportunity to close down the proxy gracefully but this is a cooperative strategy
I encounter this strange problem while using wcf services along with
L2SQL DAL.
The server is hosted at the localhost and contains an implementation of the correspondent interface. The client is familiar with the interface and occasionally queries the database via the exposed service using tcp transport.
When client runs locally everything's just fine.
But whenever client runs at another machine the 'InvalidOperationException' is thrown in the System.Data.dll (the transport still gets delivered) and over the time the channel enters 'Faulted' state(and transport fails to get delivered).
I feel I'm missing something very basic in my application.
Could anyone please point out possible reasons for such and odd behaviour?
An exception in the service will cause the channel to enter a Faulted state, if you do not clean up properly. See: http://bloggingabout.net/blogs/erwyn/archive/2006/12/09/WCF-Service-Proxy-Helper.aspx
for how to clean up the proxy when the service fails.
On your problem with L2SQL, looks like you allready found a solution.
I have WCF service hosted in console app. Service tries to connect to opened windows application via DDE protocol. No luck. Where is the problem? Console app is running in my account, as the dde windows app.
I'm not expert in this field, but I believe DDE requires that you have a running message pump (which a console application lacks), so you may have better luck hosting your WCF service in a WinForms app.
You have provided so little details about the problem that is going to be nearly impossible to give you a definitive answer. However, your comment to Allon's answer is interesting.
If i run listener in console without
WCF, all is fine
So your DDE application is listening for something? I now have to assume that you have attempted to create a DDE client that subscribes to an advisory loop via DdeClient.StartAdvise. This method of data retrieval is highly dependent on a message pumping mechanism.
When you create an instance of DdeClient it will by default create its own message pump on a separate thread to receive these advisory notifications. That would explain why it works when you leave your code in a basic console application.
However, when you mix WCF there may be some adding complexities particularly concerning threads that may have to be dealt with manually. The only way I am going to be able to tell is if you provide more information.
consider a WCF service, which is heavily used and behaves normally. But then is stopps responding. In the sevice level message trace you can see the outgoing message on the client, but no incoming message on the server. On transport level theres a incoming message and then nothing. After 60 seconds the client throws a TimeoutException.
What can cause a behavior like this?
What would you do to debug this behavior?
Is it possible that this behavior is caused by too many concurrent connections/sessions?
EDIT:
Client and Server are on the same machine. Both are .NET apps. When the client is restarted the problem sometimes does not happen. Also the problem does only appear on a single machine. I was not able to reproduce the behavior on any other machine.
Regards
Michael
I understand you have no problem on network level as you have mentioned that you can see incoming request on transport level.
So the first thing to check does the service is up and does it works if the client is on the same machine.
Also you can analyze incoming messages may be the problem can be there.
Here WireShark will be your friend.
Also check can you view the wsdl from the client machine. By the way are your clients also .NET apps?
You can configure tracing using the application’s configuration file—either Web.config for Web-hosted applications, or Appname.config for self-hosted applications by Service Trace Viewer
or use from debug tools such Debug Diag