by Derek Du

Today, I tried to run a previous WCF project and it refused to work. The error message was: OperationContext.Current is null. The project uses a third-party written WCF custom encoder that enables SOAP with Attachment, so it made that much harder to debug the issue. After struggling with it the whole day, I was surprised to find that the issue was because of a WS-Addressing Action mismatch between my client and service. It turned out that in a certain version of codes, I modified the action name of both client and service. So, today my codes were not in the latest version, thus the client and service had different action values.

What was misleading was that the error message didn’t mention anything about the action. It only said about OperationContext.Current being null. And, I explicitly used OperationContext at my client side:

This code shows the contract and binding used by this client:

The client is using a contract “PayloadsSoap” and that is the origin of the issue. On the client side, we set the WS-Addressing as http://tempuri.org/service1. (OperationContractAtrribute.Action), which should match the same property from service side. Here is the client side contract:

Note: The OperationContractAttribute.ReplyAction defines the value of SOAP action and a mismatch in that does not cause the issue I have.

I also ran a few tests after having identified the issue to be sure. In my tests, whenever there is a mismatch on WS-Addressing Action, an exception is thrown by the custom encoder that needs to edit the OperationContext.Current object. My guess is that because of the mismatch, the OperationContext used by the client becomes different from the OperationContext used by the service.

Next time I will make sure first that my local copy of codes is up-to-date.

This blog originally appeared on Derek's blog, Stuff.