Chapter 23: COM Interoperability

Overview

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 to do some refactoring, 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.

This chapter discusses the following:

• COM and .NET technologies

• Using COM objects from within .NET applications

• Using .NET components from within COM clients

• Platform invoke for invoking native methods

Like all other chapters, you can download the sample code for this chapter from the Wrox Web site at www.wrox.com.