Before you delve deeply into COM Interop, it's a good idea to understand the completely different views that managed and unmanaged code have of the world. When you have a good understanding of these two views and where they agree and disagree , it's much easier to debug the inevitable problems that COM Interop throws up.
The following list presents the major differences between these two architectures:
Coding model: The managed world uses an object-based view of code, whereas the COM world thinks of code in terms of interfaces. This means that Interop has to generate an interface to expose managed code to the unmanaged world, unless the managed code already provides such an interface.
Error handling: The usual COM practice is to return an HRESULT to signify whether a method has succeeded or failed. VB 6.0 developers get a break here because they're already used to the practice of raising errors using the Err object. COM Interop maps VB 6.0 errors to .NET exceptions, and it maps .NET exceptions to VB 6.0 errors.
Identities: COM uses globally unique identifiers (GUIDs) to identify unmanaged types and interfaces, whereas .NET uses strong names, which uniquely identify assemblies and managed types. COM Interop can generate GUIDs for .NET assemblies and strong names for COM components .
Type compatibility: Although some managed and unmanaged types are compatible, others are not. Fortunately there are .NET attributes that can solve most type compatibility problems.
Type definitions: A COM type library is optional and only contains public types, whereas .NET metadata is mandatory and describes both public and private types. COM Interop is quite successful at converting between type libraries and metadata.
Versioning: VB 6.0 allows you to extend interfaces without breaking binary compatibility, but COM interfaces are generally considered to be immutable. However, .NET interfaces can evolve while keeping the same name . When you step into the unmanaged world, you need to be careful about versioning issues, which are sometimes known as DLL Hell .
In this chapter I point out some of the issues raised by these two very different views of the world and discuss how you avoid or work around them.