Introduction

This article is in continuation to the article "Understanding Remoting" and continues forward the concepts and implementation of remoting in .NET. It is a pre-requisite to complete reading the earlier article before proceeding to this one.

Need for Configuration Files

The remote objects that you define must be registered with the remoting framework before your client code can consume them. The type of the object such as, whether it is a SingleCall or Singleton, the URI where it will be deployed, the activation requirements for managing the object lifetime, and the channels that can be used to connect to this object are some of the information specified for the registration. This information can be specified either programmatically through code or through a configuration file. The problem with hard-coding the settings is that every time, a modification happens, it requires a new compilation. For example, if you change the port number or the server settings, you have to recompile the code. This can be a pretty cumbersome and time-consuming process especially in enterprise environments.

To overcome this, you can store the settings in an external configuration file. Once you have done this, when you make any changes to the remoting settings, the classes don’t have to be recompiled. Whenever the remoting infrastructure needs to be configured, the information will simply be taken from the configuration file. This can save a lot of time and effort.

Declarative configuration, as this is called, can be specified at machine level or application level.

Types of Configuration Files

Machine Level Configuration File

Machine level settings apply to all the .NET applications present on the machine. This file is named machine.config and is typically located in the config directory of Microsoft .NET. The exact path will differ from version to version and also, the underlying OS being used. For example, on a Windows XP machine, with .NET Framework 2.0, the path would be:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG

For an IIS application, the configuration file will be web.config.

Application Level Configuration File

Application level settings, on the other hand, cater to specific applications. If you want to configure application-specific settings, you will use the application level configuration file. The naming convention for this is typically the application name followed by an exe and a config. For example, ArkLibrary.exe.config can be the name of an application level configuration file. The names are case-sensitive so you need to be careful while naming them.

The syntax for specifying settings through a configuration file is shown below:

The complete list of elements within the configuration is listed in the below table:

Table 1: List of elements within the configuration file

For detailed description of these elements, please refer to MSDN.

Example

Let us now see an example to demonstrate how to use configuration files:

Launch Visual Studio 2008 and select File-> New Project. Choose Visual C# as the language and Console Application as the project type. Rename the application as ArkServer.

Add references to the System.Runtime.Remoting assembly and the assembly where you had created the remotable class earlier (ArkLibrary in “Understanding .NET Remoting)

Select Project->Add New Item and add a new configuration file:

Add the following code within it:

Save the file as Ark.exe.config under the bin\Debug folder.

Rename the default class in the console application to ArkServer.cs.

Replace the default code in the class with the code given below:

What was done in the above class is summarized briefly here:

• The remoting configuration file, which is an application level configuration file named Ark.exe.config, is specified with the RemotingConfiguration.Configure() method.
• This method is a static method defined in the RemotingConfiguration class. The class provides several methods to help you configure the remoting infrastructure.
• The purpose of this method is to read the configuration file and configure the remoting infrastructure.
• Earlier, this method took in a single parameter but that version of the method is obsolete now. The new version of this method takes two parameters: the name of the configuration file and a boolean value indicating whether security is required or not. A value of true indicates that security is required and a value of false indicates otherwise. For TCP channels, a value of true is given. For HTTP channels, a value of false is given as typically it cannot be secured. Hence, we have given false here.
• Passing a null reference as the first parameter will cause default remoting initialization without requiring the existence of a configuration file.
• The method throws a SecurityException in case of failure.

How this method functions is described now. The method loads the configuration file into memory, parses the information specified in it. It calls the relevant methods to register the channels and objects indicated in the file. Remoting is not configured when a configuration file is loaded on application startup and happens only when this method is encountered. The server should continue to run as long as the user does not press S, hence code has been written for the same.

Next, create another configuration file, this time for the client, as follows:

Here, we have written code to register the remotable class, ArkClass. The mode attribute is not required to be specified in the client config file. The channels section is also not specified because the client makles use of the value of the URL to determine the protocol and port number. So here,

http://localhost:1234/ArkClass

will determine the channel to be Http and port number to be 1234.

Next, create another console based project in the same solution by right clicking on the Solution and then selecting Add and New Project.

Rename the project to ArkClient. Add a Project Referece to System.Runtime.Remoting. Add a reference to the dll, ArkLibrary.dll. This dll contains the remotable object.

Replace the default code in the Class1 with the following code:

What was done in the above code is summarized below:

• The client configuration file is specified using the RemotingConfiguration.Configure() method.
• The rest of the code is similar to what we had done in the earlier version of ArkBuyers (part I of this article series) except that this code is console based whereas that was Windows Forms based. As there is no combo box defined here, we do not call the GetData() method. If the phone number could not be successfully retrieved, a value of false is returned to the client. Based on whether the method returned true or false, appropriate messages are displayed.

In the remotable class, you can make a few changes, such as optionally removing the GetData() method as it won’t be invoked here. Or you can leave it as is and continue. Compile the ArkLibrary class library to generate the DLL and add the dll to both ArkServer and ArkClient applications as a reference.

Build each of the projects. To run each project, select “Debug-> Start new instance” from the context menu. The server will continue to run till you press S. When the client application runs, it asks for Buyer ID. When the end user specifies an id, the corresponding phone number has to be retrieved. To do this, the GetPhoneNumber() method of the remotable object is invoked and the relevant data is finally retrieved and displayed.

As this was an MBR, the methods will be executed at the server side. And because this is a Singleton mode, the object will retain state.

Summary

You’ve learned what is declarative configuration, what are its types, how to create configuration files and also explored an example that demonstrated remoting using configuration files.

About Medusa M

Medusa loves experimenting with technology trends, especially that of Microsoft. This author has published 14 articles on DotNetSlackers. View other articles or the complete profile here.