Chapter 4: Configuration and Deployment

Overview

THIS CHAPTER INTRODUCES YOU to the aspects of configuration and deployment of .NET Remoting applications. It shows you how to use configuration files to avoid the hard coding of URLs or channel information for your remote object.

You also learn about hosting your server-side components in Windows services or Internet Information Server (IIS)—the latter of which gives you the possibilities to deploy your components for authenticated or encrypted connections, which is covered in detail in Chapter 5.

To configure your applications, you can choose to either implement all channel and object registrations on your own or employ the standard .NET Remoting configuration files. These files are XML documents, and they allow you to configure nearly every aspect of remoting, ranging from various default and custom channels (including custom properties for your own channels) to the instantiation behavior of your objects.

The big advantage, and the main reason you should always use configuration files in production applications, is that you can change the application's remoting behavior without the need to recompile. For example, you could create a configuration file for users located directly within your LAN who might use a direct TCP channel, and another file for WAN users who will use a secured HTTP channel with SSL encryption. All this can be done without changing a single line in your application's source code.

With other remoting architectures, the choice of deployment and configuration is largely determined when choosing the framework. With Java EJBs, for example, the "container," which can be compared to an application server, defines the means of configuration and locks you into a single means of deployment. The same is true for the COM+ component, which has to be hosted in Windows Component services.

In the .NET Remoting Framework, you have several possibilities for operation: you can run your remote objects in a distinct stand-alone application (as shown in the previous examples in this book), run them in a Windows service, or host them in IIS.