Understanding COM Interop

.NET is a great platform for developing applications and many pieces of code that took lots of effort to write, is now made much simpler. As much as all of us would like to adopt .NET immediately, many organizations cannot. Lots of investment has been made developing applications using technologies like COM and these code bases cannot be junked overnight. Also, .NET may not be suitable for all types of projects. There are still some applications that are best left to low-level languages.

Given this need for organizations to preserve existing code, one of the important goals of .NET during its development was to promote interoperability with existing technologies. .NET interoperability comes into three flavors:
Interoperability of .NET code with COM components (called as COM interop)
Interoperability of COM components with .NET (called .NET interop)
Interoperability of .NET code with Win32 DLLs (called P/Invoke)
Each of these models have different requirements and best practices and this article we will discuss about COM interop. More specifically, we will see how to write a COM component and then invoke it from .NET. We will also see some best practices for developing well behaved COM interop solutions.
One important thing to understand is that components written in .NET are managed whereas components written using COM are unmanaged. Therefore, the first challenge to overcome is, to bridge these two models. Each model has its own way of memory allocation, object lifetime management and parameter passing convention that to bridge these two models require the usage of an intermediary that handles all these differences. Having an intermediary is important because we do not want applications writing this code for each application that wants to interop with COM components. The .NET developers were aware of this and thus gave an intermediary called as the Runtime Callable Wrapper (RCW).....http://www32.brinkster.com/srisamp/netArticles/article_16.htm