If you have Windows programs written prior to .NET, you probably don’t have the time and resources to rewrite everything for .NET. Sometimes rewriting code is useful for refactoring or rethinking the application architecture. A rewrite can also help with productivity in the long-term, when adding new features is easier to do with the new technology. However, there should not be a reason to rewrite old code just because a new technology is available. You might have thousands of lines of existing, running code, which would require too much effort to rewrite just to move it into the managed environment.
The same applies to Microsoft. With the namespace System.DirectoryServices, Microsoft hasn’t rewritten the COM objects accessing the hierarchical data store; the classes inside this namespace are wrappers accessing the ADSI COM objects instead. The same thing happens with System.Data.OleDb, where the OLE DB providers that are used by classes from this namespace do have quite complex COM interfaces.
The same issue may apply for your own solutions. If you have existing COM objects that should be used from .NET applications, or the other way around, if you want to write .NET components that should be used in old COM clients, this chapter will be a starter for using COM interoperability.
If you don’t have existing COM components you want to integrate with your application, or old COM clients that should use some .NET components, you can skip this chapter.