If you have Windows programs written prior to .NET, you probably don't have the time and resources to rewrite everything for .NET. 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.
This chapter discusses the following:
COM and .NET technologies
Using COM objects from within .NET applications
Using .NET components from within COM clients
Like all other chapters, you can download the sample code for this chapter from ...