.NET Remoting is among the most advanced .NET subjects. In addition to replacing DCOM and being relevant to distributed application development, remoting involves threading, Singletons, security, networking, Reflection, AppDomains, the differences between marshaling by reference and by value, SOAP, XML, serialization, interfaces, and more. Paul Kimmel makes it all seem easy.

This chapter is from the book

This chapter is from the book

The power of the passions, the force of the will, the creative energy of the imagination, these make life.

The Princess of Tivoli (Disraeli) in Paul Smith,Disraeli: A Brief
Life

Introduction

One of the splendid miseries of writing computer books is that you have to go out and get some practical experience about
the subject. Many times this is possible, but occasionally it is not. Remoting is one of the few areas in this book where
my experience is limited to nonproduction code, that is, sample applications. As I am writing this my colleagues and I are
deliberating whether or not to use Web Services or .NET Remoting on a current project. Because we will unlikely be able to
deploy clients or servers on the other end of the problem, Web Services will probably win. This brings us to the subject at
hand. What is .NET Remoting and why should you care?

Remoting is the technology used to get two applications to interchange data. It is in the same category of problem and solution
as CORBA and DCOM. Clearly Microsoft thinks that .NET Remoting is a best-of-category solution—otherwise, why would we need
something other than DCOM?

To help you understand .NET Remoting in a general sense, I will share a story with you that perhaps will help you understand
the concept behind .NET Remoting and its technology. Afterward I will include several examples that deal with the nuts and
bolts of remoting.