Category list

Common Remoting Exceptions

The .NET Remoting framework is quite friendly. If you make a mistake, you'll end up with a perplexing exception rather than a system problem or application crash. The .NET Remoting framework is complicated, however, and you're likely to encounter many trivial but frustrating problems when you're starting out with it. Most exceptions come in the form of the generic System.Runtime.Remoting.RemotingException class, with a description that provides a little more insight into the possible cause. Table 4-3 lists some common exceptions and messages and the problems that cause them.

Table 4-3. Common Remoting Exceptions

Exception	Message	Possible Cause
SocketException	No connection could be made because the target machine actively refused it.	You haven't started the component host, or the component host is listening on the wrong channel.
SocketException	No such host is known.	The host (machine) name can't be located on the network or over the Internet.
WebException	The underlying connection was closed: An unexpected error occurred on a receive.	You tried to connect to a TCP/IP server channel with an HTTP client channel.
RemotingException	TCP channel protocol violation: expecting preamble.	You tried to connect to an HTTP server channel with a TCP/IP client channel.
RemotingException	Can't load type [type name].	The component host could not find the assembly required for the remote object.
SerializationException	The type [type name] isn't marked as serializable.	You can't return an object unless it is remotable (derives from MarshalByRef_Object ) or serializable (marked with the <Serializable> attribute).
RemotingException	Object [URI] has been disconnected or doesn't exist at the server	The remote object might have been destroyed because its lease time expired .
RemotingException	The channel [channel name] is already registered.	You tried to define the same channel twice on the same machine. This could be caused by separate programs that are attempting to use the same channel (which isn't allowed), use of the wrong channel type (for example, using TCP when you really want to use TCP server and TCP client), or an attempt to use bidirectional communication over the same channel on the same machine.
RemotingException (root cause ApplicationException )	CONFIG file [filename] can't be read successfully: Invalid XML in file [filename].	You have mistyped an element in the .config file. (For example, you might have forgotten a required character or inserted an extra character.)

Summary

This chapter delved deep into one of the most flexible and sophisticated parts of distributed application development: .NET Remoting. .NET Remoting is a core part of .NET and an extremely flexible technology. Throughout the rest of this book, you'll encounter examples that employ .NET Remoting. Chapter 11 considers some advanced .NET Remoting techniques, such as dynamic registration and interface-based programming.

Remember that just because you can do something doesn't mean you should . Noted Microsoft architects have recently remarked that they've seen .NET Remoting being used in all the wrong places. If components are going to run on the same computer, for example, there's usually no reason to use .NET Remoting to communicate between them because it adds unnecessary overhead. Similarly, scattering components to different computers can help if you need sheer processing power; but if your needs are modest, the additional overhead required for network communication can contribute to an overall slowdown . The best advice is to design in several tiers and then look at the possibility of locating objects on other computers, where it makes practical sense.

We aren't quite ready to shift the discussion to architecture, however. First we need to fit a few more .NET technologies into the picture—starting with the next chapter, which discusses the revolution of XML Web services.