Remote Object Configuration 

Developers publishing or consuming remotable objects are responsible for configuration of the .NET remoting system so that applications using .NET remoting work correctly. You can do this programmatically, or using the application configuration file or the machine configuration file. Administrators can then use the .NET Framework Configuration tool to point remoting clients at different endpoints or to modify the lifetime of client-activated (<activated>) or server-activated (<wellknown>) objects where necessary.

You register your remotable classes by placing them inside the <application> element, which is a child of the <system.runtime.remoting> element. Objects that an application consumes are grouped by remote application under the <client> section within the <application> element. Objects that an application exposes are declared within a <service> section within the <application> node. If you are not hosting your remote types in Internet Information Services (IIS), you can specify a name attribute for your application that then becomes part of your activation URL, but it is not needed in any scenario. For details on hosting in IIS, see Hosting Remote Objects in Internet Information Services (IIS).

In addition, .NET remoting does not automatically pick up any remoting configuration values in the application configuration file. In order to configure remoting using a configuration file, you must call RemotingConfiguration.Configure. The only case in which the host application domain automatically loads the remoting configuration file is when your remotable type is hosted in IIS. In this case, .NET remoting will automatically pick up only the service settings from the Web.config file. Client settings will be ignored until the configuration file is again loaded with a direct call to the RemotingConfiguration.Configure method.

The following schema shows the structure of the elements that you can use to configure an application to use .NET remoting.

<configuration>

<system.runtime.remoting>

<application>

<lifetime>

<channels> (Instance)

<channel> (Instance)

<serverProviders> (Instance)

<provider> (Instance)

<formatter> (Instance)

<clientProviders> (Instance)

<provider> (Instance)

<formatter> (Instance)

<client>

<wellknown> (Client Instance)

<activated> (Client Instance)

<service>

<wellknown> (Service Instance)

<activated> (Service Instance)

<soapInterop>

<interopXmlType>

<interopXmlElement>

<preLoad>

<channels> (Template)

<channel> (Template)

<serverProviders> (Instance)

<provider> (Instance)

<formatter> (Instance)

<clientProviders> (Instance)

<provider> (Instance)

<formatter> (Instance)

<channelSinkProviders>

<serverProviders> (Template)

<provider> (Template)

<formatter> (Template)

<clientProviders> (Template)

<provider> (Template)

<formatter> (Template)

<debug>

To use the remoting settings, you must call RemotingConfiguration.Configure on the application configuration file. Note that the common language runtime automatically loads the machine configuration file before it loads the application configuration file. Do not call RemotingConfiguration.Configure on the machine configuration file. Doing so can cause exceptions when some objects that are already in memory are loaded again.

Lifetime Configuration

You specify a default lifetime for all client-activated objects and server-activated Singleton objects in an application using the <lifetime> element.

For details about programmatic configuration and lifetime concepts, see Lifetime Leases.

Instance Elements and Template Elements

There are two types of elements related to building channels: template elements and instance elements. Template elements are used to declare a channel, a server or client channel sink provider, or a server or channel sink formatter for use anywhere else in the same application merely by referencing the ID attribute of the template element.

Note

Whenever you use the type attribute in a template element to create a default configuration that uses a system-implemented type, such as a BinaryFormatter or an HttpChannel, you must specify complete type information, including version, culture, and strong-naming information. This information can be obtained from the machine.config file, or by using the global assembly cache utility Gacutil.exe. This is not necessary if the type is defined in an assembly that is not in the global assembly cache but is locatable, or if you are referencing the type in an instance element, where you can use the ref attribute.

See Also

Tasks

How to: Configure the Lifetime of a Client-Activated or Server-Activated Remote Object
How to: Configure Channels

Reference

System.Runtime.Remoting.RemotingConfiguration Class

Concepts

Configuration of Remote Applications
Channels
Channel Registration
Server-Side Registration
Client-Side Registration
Channel Registration

Other Resources

Registering Remote Objects Using Configuration Files
.NET Framework Remoting Overview