Configuration of Remote Applications
This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).
The .NET remoting infrastructure needs certain information in order to make remoting work smoothly. There are two ways to configure your remotable types: you can either call configuration methods directly in your server and client code (for details, see Programmatic Configuration), or you can create a remoting configuration section and include it in your application's configuration file, Web.config file, or Machine.config file (for details, see Remote Object Configuration). There are benefits and drawbacks to either configuration process, so your choice depends on your own preferences.
You must provide the following information to the remoting system to make your type remotable:
The type of activation required for your type.
The complete metadata that describes your type.
The channel registered to handle requests for your type.
The URL that uniquely identifies the object of that type. In the case of server activation, this means a Uniform Resource Identifier (URI) that is unique to that type. In the case of client activation, a URL that is unique to that instance will be assigned.
Both the client and the server remoting infrastructure must know this information to create proxies for and dispatch method invocations to the remote server object. Clients might also have special configurations available to them. If your client application is requesting a client-activated object, the client can request that the lifetimes associated with the instance be extended. Finally, if your client is expecting a callback of some sort, the client itself must actively register a channel to listen for that callback. (In all other cases, the .NET remoting system automatically locates a compatible client channel, if the system has one.) Servers might specify default lifetime periods for client-activated objects, or specify that a particular custom object activator be used.
If you are configuring a TCP or HTTP server channel for a .NET Framework Remoting server, and the server computer has multiple Network Interface Cards (NICs) or a NIC whose IP address is changing (such as a wireless NIC), you must configure the channel to use the machineName property to ensure that .NET Framework Remoting can locate the server computer. For more information, see the description of the machineName property in Channel and Formatter Configuration Properties.
If you provide all the information about the remotable object before trying to create an instance, you can use the new keyword (New in Visual Basic); otherwise, you must use either Activator.GetObject or Activator.CreateInstance.
.gif "Note") Note |
|---|
Although there are only a few .NET Remoting related settings in an application configuration file, most of the problems using .NET remoting occur because some of these settings are either incorrect or do not match the configuration settings for client applications. It is very easy to mistype a name, forget a port, or neglect an attribute. If you are having problems with your remoting application, check your configuration settings first. |
See Also
Reference
Concepts
Metadata Issues
Activation URLs
Programmatic Configuration
Automatic Deserialization in .NET Framework Remoting
Channel and Formatter Configuration Properties
Hosting Remote Objects in Internet Information Services (IIS)
Remoting Example: Hosting in Internet Information Services (IIS)