Introduction

Ever since the early days of Windows programming, there has been a gradual improvement in operating system stability. Much of this is due to the separation of applications into distinct processes so that each has its own area of memory. Developers have had to use many tricks to get these applications to communicate with each other. Some of these methods included using the system clipboard, sending windows messages, using the Visual Basic (VB) SendKeys function or similar, transferring message files, or declaring an area of shared memory. Each of these methods had pros and cons and were generally hacks around the separation of processes. When Microsoft s Component Object Model (COM) arrived, the situation vastly improved, and such tricks were no longer needed, but COM did introduce a number of issues with versioning, registration, and administration that a generation of Windows developers has had to deal with. Now with the .NET platform, you get cross-application communication built-in, which provides you with an amazing amount of flexibility and control as to how you want your applications to communicate with each other.

Every application on the .NET platform exists in its own unique Application Domain. And every Application Domain is able to expose objects to the outside world from any type of application from simple console applications to Windows Forms and Internet Information Server (IIS) hosted applications. To enable applications running in one Application Domain to communicate with other applications in another Application Domain, you use remoting. Or you could say remoting allows...