Why Build a .NET Component to Look Like a COM Component?

The previous two chapters showed why .NET should and does interoperate with existing COM components and DLLs. The reasons why existing COM components and DLLs should be able to interoperate with .NET are similar yet different. You want to have access to existing COM components and DLLs so that any development does not need to involve a full port of the functionality that has already been developed. Interop in the other direction (from legacy code to .NET) allows development to be done with the tools and facilities of the .NET Framework and still have the code accessible from legacy code (unmanaged code). In addition, consider the following as you consider your next project:

• Many significant unmanaged clients and hosts still exist and are not likely to be changed soon. ASP.NET is primarily focused on building server-side components. Internet Explorer still relies on calling unmanaged COM components on the client side. It will be necessary for your application to build components that Internet Explorer can call as unmanaged COM components. Office XP has extensive hooks available that allow Excel, Word, PowerPoint, and the other Office XP applications to be extended with COM components. You will later see a simple example of interoperation with an Office XP application. The Windows shell currently does not have specific knowledge about managed code. Scripts in particular can interoperate only with a COM interface. If your development cycle includes Visual Basic 6.0, then your component needs to have a COM interface.

• Consider ease of development. Developing a COM component within the .NET Framework is much simpler than that required for an unmanaged COM component. Managed code is the simplest way to build COM objects. For example, the CLR handles the lifetime management of the component. With the interop layer that is available, you have little reason to develop new components with unmanaged code.