Channel Registration
This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).
In the .NET remoting system, channel objects provide data transportation when a client calls a method on a remote object. The remote service might support more than one channel and it is the responsibility of the client application to pick the channel best suited to meet its requirements. If you do not specify a channel in your client configuration file and your client calls a method on a remote object, one of the default channel implementations (HttpChannel or TcpChannel) will be loaded by the .NET remoting system, if one of them supports the client's network protocol. However, if the client expects any callback functions or events, you must specify a client channel to listen for that callback function.
You can register a channel in two ways. Either you declare a channel template, and then reference this channel in your application, or you specify all channel information directly in your application. The default channel templates in the Machine.config file should be sufficient for most applications and can be referenced from the <channels> tag (within the <application> tag) by using the ref attribute of the <channel> tag and specifying either "tcp" or "http". You do not need to specify a port attribute when you use an HttpChannel, but you must specify one when you use the TcpChannel.
If your application exposes a server object, you must register a channel so that client applications can communicate with your object. You can do this either programmatically by using the ChannelServices.RegisterChannel method or by registering the channel in the configuration file.
If your application consumes objects, you must register a channel that knows how to reach them (this is mandatory in all cases if you expect to listen for callback functions or events), unless the service object uses one of the default client channels listed in the machine configuration file.
For detailed examples, see Remoting Example: Channel Sink Provider, the <channel> instance element, and the <channel> template element.
Channel Sinks
Channel sinks allow developers to customize the serialization and transport of messages between the client and remote services. Channel sinks are created by sink providers, and both client sink providers and server sink providers can be specified in the configuration file. Server channel sinks are invoked when messages are sent to and from the server, and they are specified inside the <serverProviders> element. Client sinks are invoked when messages are sent to and from the client and are specified inside the <clientProviders> element.
Channels must have a formatter sink. Formatter sinks serialize a message. The .NET Framework includes formatters for binary and SOAP serialization.
It is important to note that once you specify a custom formatter, the .NET remoting system assumes that you will specify all channels in the order you want them. As a result, if you declare a custom channel that uses a custom formatter, you must also specify what other providers you want to be in the channel sink chain. No default channel sinks will be added.
See Also
Tasks
How to: Create a Channel Template in a Configuration File
Reference
System.Runtime.Remoting.RemotingConfiguration Class
Concepts
Configuration of Remote Applications
Remote Object Configuration
Other Resources
Registering Remote Objects Using Configuration Files
.NET Framework Remoting Overview
.NET Framework Remoting Overview