I've just spent a couple of hours trying to track down a customer issue with one of our WCF services. Below was part of the unit test I was suing to test the service.
using (var client = new MemberServiceClient())
{
client.ClientCredentials.UserName.UserName = ConfigurationManager.AppSettings["username"];
client.ClientCredentials.UserName.Password = ConfigurationManager.AppSettings["password"];
client.CreateMember(mem);
client.DeleteMember(mem.ExternalRef);
}
and the exception it was throwing was:
failed: System.ServiceModel.CommunicationObjectFaultedException : The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.
Server stack trace:
at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ClientBase`1.Close()
at System.ServiceModel.ClientBase`1.System.IDisposable.Dispose()
When I debugged the code the code actually fails at the CreateMember line not at the close method indicated at by the stack trace. Then I realised that this was one of thoes WCF silly moments - don't use using blocks!. Yes believe it or not if you use a using block around a WCF client and it fails when the using block calls the dispose method it throws a new excpetion masking the real exception.
The code below is some helper methods we use for making WCF clients are cleaned up correctly.
/// <summary>
/// WCF proxys do not clean up properly if they throw an exception. This method ensures that the service proxy is handeled correctly.
/// Do not call TService.Close() or TService.Abort() within the action lambda.
/// </summary>
/// <typeparam name="TService">The type of the service to use</typeparam>
/// <param name="action">Lambda of the action to performwith the service</param>
public static void Using<TService>(Action<TService> action)
where TService : ICommunicationObject, IDisposable, new()
{
var service = new TService();
bool success = false;
try
{
action(service);
if (service.State != CommunicationState.Faulted)
{
service.Close();
success = true;
}
}
finally
{
if (!success)
{
service.Abort();
}
}
}
Changing the code to using our service helper methods.
ServiceHelper.Using(
client =>
{
client.ClientCredentials.UserName.UserName = ConfigurationManager.AppSettings["username"];
client.ClientCredentials.UserName.Password = ConfigurationManager.AppSettings["password"];
client.CreateMember(mem);
client.DeleteMember(mem.ExternalRef);
}
);
Now the code exposed the actual exception that was causing the issue.
failed: System.ServiceModel.Security.MessageSecurityException : An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
----> System.ServiceModel.FaultException : An error occurred when verifying security for the message.
Server stack trace:
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
This exception had me stumped as I had never come across it before but after a bit of digging I discovered that the server time was 7 minutes late and that changing the time fixed the issue. Still trying to figure out how the server's time got out of synced.