There are three types of message encodings that come with WCF: text, binary, and MTOM. Text is the traditional way of encoding an XML document; MTOM is an interoperable way to create messages with attachments; and binary is an optimized format. The binary message encoder requires you to use SOAP 1.2 and any version of message addressing. Validation for the message encoder checks that you are using SOAP 1.2. A transport can supply its own native version of addressing, but the HTTP, TCP, and named pipe transports don't work with this for the binary encoding. The validation doesn't check to make sure that you have some kind of message addressing, so if you are using AddressingVersion.None, then that won't show up as an error until you try to send a message.

It may be difficult to figure out the cause of the error because the resulting message looks invalid and the connection just gets refused. If you are capturing all of the exceptions that occur though, you should see something that looks like one of these stack traces when you have an invalid configuration.

The stack trace when using HTTP is going to look like:

System.ServiceModel.Channels.BinaryMessageEncoderFactory.BinaryMessageEncoder.ReadMessage + 0x299 bytes
System.ServiceModel.Channels.HttpInput.DecodeBufferedMessage + 0x56 bytes
System.ServiceModel.Channels.HttpInput.ReadBufferedMessage + 0x7e bytes
System.ServiceModel.Channels.HttpInput.ParseIncomingMessage + 0x9e bytes
System.ServiceModel.Channels.HttpRequestContext.CreateMessage + 0x2e bytes
System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived + 0x99 bytes
System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore + 0x231 bytes
System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext + 0x1e bytes
System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame + 0x28 bytes
System.Net.LazyAsyncResult.Complete + 0x7f bytes
System.Net.LazyAsyncResult.ProtectedInvokeCallback + 0x8b bytes
System.Net.ListenerAsyncResult.WaitCallback + 0x22a bytes
System.Threading._IOCompletionCallback.PerformIOCompletionCallback + 0x68 bytes

The stack trace when using TCP or named pipes is going to look like:

System.ServiceModel.Channels.TransportOutputChannel.TransportOutputChannel + 0x8b bytes
System.ServiceModel.Channels.FramingDuplexSessionChannel.FramingDuplexSessionChannel + 0x4f bytes
System.ServiceModel.Channels.FramingDuplexSessionChannel.FramingDuplexSessionChannel + 0x38 bytes
System.ServiceModel.Channels.ServerSessionPreambleConnectionReader.ServerFramingDuplexSessionChannel.ServerFramingDuplexSessionChannel + 0x29 bytes
System.ServiceModel.Channels.TcpDuplexChannelListener.System.ServiceModel.Channels.ISessionPreambleHandler.HandleServerSessionPreamble + 0x99 bytes
System.ServiceModel.Channels.ConnectionOrientedTransportManager.OnHandleServerSessionPreamble + 0x53 bytes
System.ServiceModel.Channels.ConnectionDemuxer.OnSessionPreambleKnown + 0xac bytes
System.ServiceModel.Channels.ServerSessionPreambleConnectionReader.ContinueReading + 0x11d bytes
System.ServiceModel.Channels.ServerSessionPreambleConnectionReader.StartReading + 0x4b bytes
System.ServiceModel.Channels.ConnectionDemuxer.OnDuplexConnection + 0xf6 bytes
System.ServiceModel.Channels.ConnectionDemuxer.OnConnectionModeKnownCore + 0x214 bytes
System.ServiceModel.Channels.ConnectionDemuxer.OnConnectionModeKnown + 0x7 bytes
System.ServiceModel.Channels.ConnectionModeReader.Complete + 0xf bytes
System.ServiceModel.Channels.ConnectionModeReader.ReadCallback + 0x74 bytes
System.ServiceModel.Channels.SocketConnection.FinishRead + 0x19 bytes
System.ServiceModel.Channels.SocketConnection.AsyncReadCallback + 0x13b bytes
System.ServiceModel.Channels.OverlappedContext.CompleteCallback + 0x88 bytes
System.ServiceModel.Diagnostics.Utility.IOCompletionThunk.UnhandledExceptionFrame + 0x2f bytes
System.Threading._IOCompletionCallback.PerformIOCompletionCallback + 0x68 bytes

Update: Made it clearer why the message encoder needs a real addressing version in this case.

Next time: Live from TechEd