.NET Reference Guide

Remoting Configuration

Last updated Jul 22, 2005.

There are two ways to configure a program to use .NET Remoting. The code in the previous examples calls the configuration methods directly, setting up the channels and registering the objects for remoting. This is termed programmatic configuration. It can be useful at times but it ties your application to specific ports and formatters, and to specific activation types. In order to change anything about your remoting configuration, you have to change the source code and recompile your application.

The other way to configure your remoting application is through application configuration files, which will allow you to change ports, formatting modes, and other settings without having to recompile the program: simply change some settings in the application's configuration file and restart the program.

To modify your program so that it can use a configuration file, you replace all of the code that registers the channels and objects with a single call to the RemotingConfiguration.Configure method. That method will load the specified configuration file and use the settings to configure the channel and register the objects.

In the configuration file you specify the channels and ports that your application will use, and the types of objects to be registered. It's the same information that you'd supply in programmatic configuration, just in a slightly different format. Here are examples of server and client configuration files.

Server remoting configuration (server.config)

<configuration>
   <system.runtime.remoting>
     <application name="server">
        <service>
          <activated type="remote.ServiceClass, remote"/>

        </service>
        <channels>
          <channel ref="http" port="8080">
             <serverProviders>
               <formatter ref="binary" typeFilterLevel="Full"/>

             </serverProviders>
             <clientProviders>
               <formatter ref="binary"/>
             </clientProviders>
          </channel>

        </channels>
     </application>
   </system.runtime.remoting>
</configuration>

Client remoting configuration (client.config)

<configuration>
   <system.runtime.remoting>

     <application name="client">
        <client url = "http://localhost:8080">
          <activated type="remote.ServiceClass, remote"/>
        </client>
        <channels>

          <channel ref="http" port="0">
             <serverProviders>
               <formatter ref="binary" typeFilterLevel="Full"/>

             </serverProviders>
             <clientProviders>
               <formatter ref="binary"/>
             </clientProviders>
          </channel>

        </channels>
     </application>
   </system.runtime.remoting>
</configuration>

Note that the typeFilterLevel property is added only to the server providers. If you add that property to a client provider, the program will throw an exception when it tries to read the configuration file. Also note that the typeFilterLevel property is used only for .NET Framework 1.1 Remoting. That property is not implemented in version 1.0, and its existence in the configuration file will cause an exception if used in a .NET Framework 1.0 Remoting application.

For a full description of remoting configuration files, see the MSDN article Format for .NET Remoting Configuration Files.

To use these configuration files in our Remoting test application, place those files (server.config and client.config) in the directory that contains the server.exe and client.exe programs.

Using application configuration files greatly simplifies the code required to set up a remoting application. For example, the single line shown here takes the place of all the configuration code in the server.cs program's Main method:

RemotingConfiguration.Configure("server.config");

Similarly, in the client.cs program replace the Doconfiguration method with this:

private static void DoConfiguration(bool ClientActivate)
{
   RemotingConfiguration.Configure("client.config");
}

The configuration files shown set client activation--each client gets its own object. If you want to configure for Singleton mode, change the <service> section of the server's configuration file so that it reads:

<service>

   <wellknown
     type="remote.ServiceClass, remote"
     objectUri="ServiceURI"
     mode="Singleton"
   />
</service>

And change <client> section of the client's configuration file so that it reads:

<client url = "http://localhost:8080">
   <wellknown
     type="remote.ServiceClass, remote"
     url="http://localhost:8080/ServiceURI"

   />
</client>

For SingleCall, just change the mode setting in the server's configuration file above to "SingleCall".

This change eliminates the ability to change the object activation method, but it would be easy enough to create separate configuration files and load the appropriate one based on the supplied command line parameter.

Note that you can define multiple remoting objects in the configuration files, with different activation types. All you need is a separate activated or wellknown entry for each object in the server and client configuration files.