A very weird bug

.. with an even weirder resolution

The other day I was working with a consultant from another firm to try connect our systems together. Previously we had exchanged WSDLs and even a stub service so we didn't expect to many problems implementing the real stuff.

The other client had brought his own laptop and that was quickly hooked up into the network. That was an easy start.

But ...

Things started to get really weird when I tried to connect my client app to his service. To make it a little more clear to you all: the service was a .NET 3.5 WCF Service and I was consuming it using a .NET 2.0 webservice client. The 2.0 bit was manadtory as our application is still limited to that version of the .NET Framework.

We were greeted with the following very weird error:

The message with Action 'http://tempuri.org/ITheOtherService/GetObjects' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

Googling it didn't give me a clue.

To add some more info: he was running his own domain and Active Directory on his machine. And I also had to use a NetworkCredential to get access to the service. I could see the MEX output in Internet Explorer (using the correct credentials) so connection was verified. We were connecting using the IP address of his machine.

Question marks all over

Completely baffled he gave me a test application that he had used to test the setup with a colleague in his office. We got a error message that prompted me to add the hostname and IP address to my hosts file. We had an error about linked XSD files that couldn't be found because the hostname could ot be resolved.

After that little hack we had no problem making call and getting results. Completly stunned we stared at our screens. OK, fine by me.

The big application where all the work was made still did not function. Still showing the same error message.

Another even simpler app was created, making a simple call to the service. And it worked. But still not in the big application we needed to hook up.

Details are the devil's hiding place

In another test run I then saw that I had configured the big application using the IP address. The hostname was not yet in the hosts file when I first configured the service address.

The test applications we used both of them used the host name in stead of the IP address and they worked.

After having changed the configuration to use the hostname evrything started working.

I still haven't found out why it did.

Well, who cares?

We then continued to do the testing and had to make onlysome small changes as we both had done a great job in building our apps to mutual specs. So, it was all in all a great success. But something keeps itching me.

Well, who cares why it worked with hostnam? Well I do care! I have no real idea what the reason is why it worked one way and not the other. SO, if any of you can point me to the reason of this, please leave it in a comment.

Also, maybe this story helps you to solve your weird error. If so, please leave a commoent.