The NGWS frameworks and runtime is in the logical line of progression from COM. COM Interop enables legacy COM components to interoperate with NGWS components.
The Microsoft Component Object Model (COM) differs significantly from the NGWS object model. For example, clients of COM objects must manage the lifetime of those objects; the NGWS runtime manages the lifetime of objects in its environment. Clients of COM objects discover whether a service is available by requesting an interface that provides that service and getting back an interface pointer or not. Clients of NGWS objects can obtain a description of an object’s functionality using Reflection.
Further, NGWS objects reside in memory that is managed by the NGWS execution environment. The NGWS execution environment can move objects around in memory for performance reasons and update all references to the objects it moves. Unmanaged clients, having obtained a pointer to an object, rely on the object’s remaining at the same location. These clients have no mechanism for dealing with an object whose location is not fixed.
To simplify interoperation between the NGWS runtime and COM and to ease the migration path, the NGWS runtime conceals from both clients and servers the differences in these object models. If you have a code base that uses COM, your code can interact with NGWS objects as if they were COM objects. Similarly, NGWS objects can interact with COM objects as if they were NGWS objects.
For example, COM objects pass HRESULTs, while managed objects throw exceptions. When a NGWS client calls a method on a COM object, the NGWS runtime converts any failure HRESULT it obtains into an exception. It then throws this exception to the managed client, and the client catches the exception just as if it were thrown by a managed server object. The managed client code needs no awareness of HRESULTs, nor does the unmanaged COM object code need any awareness of exceptions.
This guide to interoperation explains the following: