Part II: PInvoke and COM Interoperability
Part II of the Migration Guide discusses the use of Platform Invocation Services, or PInvoke, provided by the .NET Framework common language runtime. PInvoke provides a direct way to use C-style functions in existing native DLLs in a managed application. In contrast to languages like C# and Visual Basic where explicitly using the PInvoke mechanism is the only option, developers using Managed Extensions for C++ generally do not have to do this extra work and can just call unmanaged APIs by including the header file and linking with the import library. This feature is called "It Just Works," or IJW. Both IJW and the
DLLImport PInvoke attribute use the same underlying mechanism so it is useful to understand that mechanism in some detail. In addition, there are some cases where explicitly using the PInvoke mechanism might be beneficial.
Managed Extensions can also be used to directly wrap the underlying C++ class of a COM object. This can provide better performance than using the COM interface and a runtime callable wrapper (RCW) because there can be less interoperability overhead and much closer control of how members are wrapped. For some COM objects, it may not be possible to use the Type Library Importer (Tlbimp.exe) to create an assembly for the COM object, and using Managed Extensions to write a custom wrapper provides a solution for this.
A common issue with PInvoke and COM interoperability is that of conflicting names. Two scenarios in which they arise are covered: conflicts between names defined in native header files and assemblies in the same application; and conflicts arising from macro expansions by the preprocessor. Several techniques are given that can prevent these conflicts from occurring.