This article has been excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors of C# Corner.
Remoting configuration files, like other configuration files in .NET, are Extensible Markup Language (XML) files that use the .config extension. Configuration files can be used in remoting in lieu of source code creation and registration. In the examples so far, there hasn't been a desperate need for configuration files, but as we get into customized sinks, the amount and complexity of code required to create and register remote objects increases dramatically. Configuration files also permit configuration changes without code changes.
The naming convention for remoting configuration files is the executable program name and extension, with a .config extension. Thus, for ClientActivatedServerExe.exe, the configuration file would be named ClientActivatedServerExe.exe.config. At this point, it should be evident that less wordy project names are a good idea! The location of the configuration file must be in the same directory as the executable file.
The configuration files are located in the Samples1 with the source files in the directories of the four executable files. They should be moved to the respective "bin\debug" directories.
Listing 25.19 is an example of the configuration file for ClientActivatedServerExe. The XML declaration tag <?xml version="1.0 ?>, although not required by the XML specification, will be used in all examples, because of convention.
Listing 25.19: ClientActivatedServerExe.exe.config
<?xml version="1.0" ?>
<configuration>
<system.runtime.remoting>
<application name="Simple">
<service>
<activated type="SimpleObjectLib.SimpleObject, SimpleObjectLib"/>
</service>
<channels>
<channel ref="TCP Server" name="Client Activated Tcp Server" port="1234"/>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
This is the server's configuration file, and like all .NET configuration files, the root element is <configuration>. Remoting configuration is placed in the subelement <system.runtime.remoting>. This is a configuration for a client-activated object. The <application> tag contains the optional name attribute that identifies the URI of the remote object. If we dropped the name attribute, the client's configuration tag, below, would have to be changed to <client url="tcp://localhost:1234">.
The two subelements of <application> are <service> and <channels>. An optional subelement is a <lifetime> tag. This defines the leasing lifetime of all remote objects on the server.
The <service> tag contains information about the remote objects and is a server-specific element. The <channels> tag is common to both client and server configuration and contains information about the channels to be used by the remote object. Both of these elements can encapsulate multiple remote objects and channels.
The <activated> element identifies the remote object as being client activated. The type attribute gives the remote object's name and assembly. Two optional attributes deal with leasing, leasetime and renewoncall. These can be used to override the default time associated with those leasing properties.
The <channel> tag on the server contains two attributes. The type attribute, as with the other type attributes discussed so far, names the channel type and the assembly to be used. The port attribute indicates the port the channel will listen on.
Listing 25.20: ClientActivatedClientExe.exe.config.
<?xml version="1.0" ?>
<configuration>
<system.runtime.remoting>
<application name="ClientActivatedClientExe">
<client url="tcp://localhost:1234/Simple">
<activated
type="SimpleObjectLib.SimpleObject, SimpleObjectLib"/>
</client>
</application>
</system.runtime.remoting>
</configuration>
The client configuration file (see Listing 25.20) is very similar to the server's. The primary difference is the server's <service> tag counterpart, the <client> tag. The <client> element contains the url attribute, which, as always, identifies the location of the remote object. Using configuration files in source code is straightforward.
Listing 25.21: ClientActivatedServer.cs
static void Main(string[] args)
{
string file = "ClientActivatedServerExe.exe.config";
RemotingConfiguration.Configure(file);
}
Simply call RemotingConfiguration.Configure() with the name of the configuration file as a parameter (see Listing 25.21). Remember that the configuration file must be in the same directory as the executable file, or the path must be included in the configuration file's name parameter. To see that the channel has been created and that channel and remote object have been registered, you can use the RegisteredChannels property from ChannelServices and the RemotingConfiguration's GetRegisteredActivatedServiceTypes() method.
The server-activated example (see Listing 25.22) demonstrates another facet of remoting configuration files, the template.
Listing 25.22: ServerActivatedServerExe.exe.config
<?xml version="1.0" ?>
<configuration>
<system.runtime.remoting>
<channels>
<channel id="Http Server"
name="Server Activated"
type="System.Runtime.Remoting.Channels.Http.HttpServerChannel, System.Runtime.Remoting"
port="1234"/>
</channels>
<application name="ServerActivatedServerExe">
<service>
<wellknown
mode="SingleCall"
type="SimpleObjectLib.SimpleObject, SimpleObjectLib"
objectUri="Simple">
</wellknown>
</service>
<channels>
<channel ref="Http Server"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
We have used a template for the <channels> element. How is this beneficial? The id attribute in the <channel> element provides a label that can be referred to in the <application> section. Notice, also, the template is outside the body of the <application>. The <channel> tag attribute ref is the link to channel information. This allows us to create a common file for both the server and the client. In the example in Listing 25.22, the template is in the same file, but in the real world, the scenario would likely be in the format shown in Listings 25.23 and 25.24.
Listing 25.23: The Common Template Configuration File
<?xml version="1.0" ?>
<configuration>
<system.runtime.remoting>
<channels>
<channel id="Http Server"
name="Server Activated"
type="System.Runtime.Remoting.Channels.Http.HttpServerChannel, System.Runtime.Remoting"/>
</channels>
</system.runtime.remoting>
</configuration>
Listing 25.24: The Server's Configuration File
<?xml version="1.0" ?>
<configuration>
<system.runtime.remoting>
<application name="ServerActivatedServerExe">
<service>
<wellknown
mode="SingleCall"
type="SimpleObjectLib.SimpleObject, SimpleObjectLib"
objectUri="Simple">
</wellknown>
</service>
<channels>
<channel ref="Http Server" port="1234"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
To access these two files is simply a matter of calling as follows:
RemotingConfiguration.Configure( template configuration file name);
and
RemotingConfiguration.Configure( server's configuration file name);
RemotingConfiguration reads the directives in the template and applies them to the <application> segment whenever it encounters a ref attribute. The usefulness of this approach will become evident when configuring custom channel sink providers, discussed later in the coming article.
Server-activated objects (Listing 25.24) are distinguished from client-activated objects by the <activated> element's corresponding tag <wellknown>. The <wellknown> element's attributes mode, type, and objectUri mirror the parameters in earlier source code. It should be apparent that this is a server configuration file from the <service> tag.
The examples in this chapter were initially coded using Visual Studio .NET Beta2. RemotingConfiguration.Configure behaves differently in the release candidate. Listing 25.22 executed as expected in Beta2, loading the remoting DLL located in the global assembly cache (GAC). The release candidate, however, threw a "File Not Found" exception. This was unexpected behavior for an assembly in the GAC. To overcome this, highlight the remoting DLL and change Copy Local in properties to true.
![Figure-26.15.gif]()
Figure 25.15: Project Properties
The client configuration file for server-activated objects differs only slightly from the clientactivated configuration (see Listing 25.25).
Listing 25.25: ServerActivatedClientExe.exe.config
<?xml version="1.0" ?>
<configuration>
<system.runtime.remoting>
<application name="ServerActivatedClientExe">
<client url="http://localhost:1234/Simple">
<wellknown
type="SimpleObjectLib.SimpleObject, SimpleObjectLib"
url="http://localhost:1234/Simple">
</wellknown>
</client>
<channels>
<channel ref="Http Client"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
The <wellknown> tag contains the ever-present type attribute. The additional url attribute seems redundant because of the <client> element url attribute. Don't be misled. The <wellknown> element's url attribute is mandatory, whereas in this case the <client> element's url is optional.
Conclusion
Hope this article would have helped you in understanding .NET Remoting Configuration. See other articles on the website on .NET and C#.
![visual C-sharp.jpg]() |
The Complete Visual C# Programmer's Guide covers most of the major components that make up C# and the .net environment. The book is geared toward the intermediate programmer, but contains enough material to satisfy the advanced developer. |