Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Custom Binding Transport and Encoding

A custom binding is defined by an ordered list of discrete binding elements. This sample demonstrates how to configure a custom binding with various transport and message encoding elements.

Note Note

The setup procedure and build instructions for this sample are located at the end of this topic.

This sample is based on the Self-Host, and has been modified to configure three endpoints to support HTTP, TCP, and NamedPipe transports with custom bindings. The client configuration was similarly modified, and the client code changed to communicate with each of the three endpoints.

The sample demonstrates a how to configure a custom binding that supports a particular transport and message encoding. This is accomplished by configuring a transport and a message encoding for the binding element. The ordering of binding elements is important in defining a custom binding, because each represents a layer in the channel stack (see Custom Bindings). This sample configures three custom bindings: an HTTP transport with text encoding, a TCP transport with text encoding, and a NamedPipe transport with a binary encoding.

The service configuration defines the custom bindings as follows:

<bindings>
    <customBinding>
        <binding name="HttpBinding" >
            <textMessageEncoding 
                messageVersion="Soap12Addressing10"/>
            <httpTransport />
        </binding>
        <binding name="TcpBinding" >
            <textMessageEncoding />
            <tcpTransport />
        </binding>
        <binding name="NamedPipeBinding" >
            <binaryMessageEncoding />
            <namedPipeTransport />
        </binding>
    </customBinding>
</bindings>

When you run the sample, the operation requests and responses are displayed in both the service and client console window. The client communicates with each of the three endpoints, accessing first HTTP, then TCP, and finally NamedPipe. Press ENTER in each console window to shut down the service and client.

The namedPipeTransport binding does not support machine-to-machine operations. It is used only for communication on the same machine. Therefore, when running the sample in a cross-machine scenario, comment out the following lines in the client code file:

CalculatorClient client = new CalculatorClient("default");
Console.WriteLine("Communicate with named pipe endpoint.");
// Call operations.
DoCalculations(client);
//Closing the client gracefully closes the connection and cleans up resources
client.Close();
NoteNote

If you use Svcutil.exe to regenerate the configuration for this sample, be sure to modify the endpoint name in the client configuration to match the client code.

To set up, build, and run the sample

  1. Ensure that you have performed the One-Time Setup Procedure for the Windows Communication Foundation Samples.

  2. To build the C#, C++, or Visual Basic .NET edition of the solution, follow the instructions in Building the Windows Communication Foundation Samples.

  3. To run the sample in a single- or cross-machine configuration, follow the instructions in Running the Windows Communication Foundation Samples.

Important note Important

The samples may already be installed on your machine. Check for the following (default) directory before continuing.

<InstallDrive>:\WF_WCF_Samples

If this directory does not exist, go to Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) Samples for .NET Framework 4 to download all Windows Communication Foundation (WCF) and WF samples. This sample is located in the following directory.

<InstallDrive>:\WF_WCF_Samples\WCF\Basic\Binding\Custom\Transport

Show:
© 2015 Microsoft