Introducing Microsoft .NET (Pro-Developer)

In the previous example, I wrote code to create and register the channels and to bind the remoting object to the infrastructure. But one of the coolest features of remoting is that you don’t have to write code to do all of this. You can configure almost everything on both host and client by using configuration files, allowing much more flexibility than if you hard-code the operations. You’ll find the sample programs demonstrating the use of configuration files in the sample code directory \ConfigFile.

You can control almost all aspects of remoting with configuration files instead of code.

Instead of writing the host code that I showed in Listing 10-1, I could accomplish the same thing with the configuration file shown in Listing 10-4. My host calls the function Runtime.Remoting.RemotingConfiguration.Configure, passing the name of the configuration file. This function reads the file’s contents and performs the initialization that it specifies—in this case, creating and registering a TCP channel with a different port number and binding an object to the remoting runtime. As a lab exercise, why don’t you try changing the code to use an HTTP channel instead?

File configuration makes your applications more flexible.

Listing 10-4: Server-side configuration file.

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <channels> <channel ref="tcp" port="1235"/> </channels> <service> <wellknown mode = "Singleton" type="ConfigFileRemotingObjectVB.Class1, ConfigFileRemotingObjectVB" objectUri="ConfigFileUriName" /> </service> </application> </system.runtime.remoting> </configuration>

The remoting client as well as the host can benefit from the use of configuration files. Instead of the client code you saw in the first example, with all configuration settings hard-coded into the function calls, I can write the configuration file that you see in Listing 10-5. The client then calls the same RemotingConfiguration.Configure function that the host did, passing it the client’s own configuration file. This takes care of creating and registering channels.

The remoting client as well as the server can benefit from the use of configuration files.

Listing 10-5: Client-side configuration file.

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <client> <wellknown type="ConfigFileRemotingObjectVB.Class1, ConfigFileRemotingObjectVB" url="tcp://localhost:1235/ConfigFileUriName" /> </client> </application> </system.runtime.remoting> </configuration>

Another great benefit of using configuration files is that a client configured in this way doesn’t need to call Activator.GetObject to create the object. Instead, it can simply use the new operator, as shown in Listing 10-6. The remoting infrastructure says, “Aha! The client’s creating an object of this class, but he’s told me that it’s remoted, so I’ll create it remotely on the specified server instead of locally.” It’s easier to write and harder to get wrong. I’ll use configuration files whenever possible for the duration of this chapter.

Listing 10-6: Client-side code using a configuration file.

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As _ System.EventArgs) Handles Button2.Click ’ Create the object. Configuration file causes this call to be ’ sent to the Activator, which also knows about remoting URL ’ from the config file. Dim foo As New ConfigFileRemotingObjectVB.Class1 ’ Call the method as if the object were local Label1.Text = foo.GetTime(CheckBox1.Checked) End Sub