COM Interop
COM Interop COM Interop is used in two scenarios: (1) When you want a managed code (.NET) application or component to consume a COM component or (2) when you want an unmanaged (Win32/COM) application or component to consume a .NET component. Both of these scenarios are shown in Figure 6-1. Figure 6-1. The two COM Interop scenarios. Scenario 1 will probably be the most widely used initially because most people who start using the .NET Framework will have a large existing code base of unmanaged code that they will want to reuse. However, don't underestimate the importance of scenario 2. Let's say that you have two COM objects, object A and object B, and let's say that object B uses the services of object A in its implementation as shown in Figure 6-2. Figure 6-2. The importance of COM to .NET Interop. The only way that you can migrate object A to .NET without also migrating object B at the same time is for the new .NET implementation of object A to continue to expose itself as a COM object through COM Interop to object B. One of the key goals of COM Interop is to make interoperation between COM and .NET as transparent as possible. In other words, when you are using a COM object from a .NET client, the COM object should appear to the .NET client to be just another .NET component. You should be able to instantiate it using the new operator, and you should not have to manage the object's lifetime manually using the AddRef and Release methods . Ideally, the object should have the same metadata associated with it that you would have with a regular .NET object. Similarly, if you use a .NET component from a COM or Win32 client, the .NET component should appear to be just like any other COM object. You should instantiate it with CoCreateInstance (or one of the other COM activation functions). You should use reference counting through the IUnknown interface to control the life cycle of the object. In Chapter 2, I compared the .NET Framework to COM. In that chapter, you saw that that COM and the .NET Framework implement naming, object lifetime management, runtime type information inspection, location transparency, and versioning in very different ways. In order to have seamless interoperation between .NET and COM, there needs to be a piece of software that sits between the .NET consumer and the COM object or the Win32/COM consumer and the .NET object. This software bridges the large gap between these two completely different object infrastructures . This software is called a Run-time Callable Wrapper (RCW) in the case of a .NET consumer using a COM object and a COM Callable Wrapper (CCW) in the case of a Win32/COM consumer using a .NET object. RCWs and CCWs are the key to the seamless interoperation between COM and .NET. Let's see how it works. |
 | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 119