OperationContext.Current is Null

Today I tried to run a past 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 harder to debug the issue. After struggled 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 and today my codes were not at the latest version thus the client and service were having 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 have explicitly used OperationContext at my client side:

PayloadsSoapClient Client = new PayloadsSoapClient("CustomBinding_PayloadsSoap_Swa");
using (OperationContextScope scope = new OperationContextScope(Client.InnerChannel))

And the code below shows the contract and binding used by this client:

 <client>
      <PayloadsSoap name="CustomBinding_PayloadsSoap_Swa"/>
</client>

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

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://tempuri.org", 
ConfigurationName="PayloadsSoap")]
public interface PayloadsSoap
{
[System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/service1", 
ReplyAction="http://tempuri.org/service1Response")]
service1Response service1(service1Request request);
}

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

I have also run 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 client becomes different from the OperationContext used by the service.

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s