Connecting to COM and. NET (1) Preliminary knowledge

This code is written using ISO C + + and the. NET V1.1 Framework (VS 2003), but it works well for all languages that support the. NET Framework

First, the preface

Because traditional COM technologies use static unmanaged programming, and. NET uses dynamic managed programming, this topic essentially discusses a special case of interoperability between managed and unmanaged code. The current. NET v2.0 provides the following three types of interoperability:

Module-Level P/invoke methods

This approach is suitable for calling unmanaged functions implemented in dynamic-link libraries (DLLs), such as DLLs in the Win32 API. will be discussed in the next section;

Component-level COM interop methods

This is the highlight of this article, which is divided into two sections:

1, the way to export the type library: the protagonist of this article;

2, the use of the Encapsulation class method: The method is unique to the CLI C + +, the framework automatically generate the wrapper class (in the COM client for unmanaged header file code), the principle of the same as the third interop;

Code-level C + + Interop methods

This approach is unique to CLI C + +, which can only be used in the VS 2005 and above versions. The implementation is very simple, the packaging of external DLLs are all generated by the wizard, do not have to write a line of code, so this article is no longer described. (Another reason is that I temporarily do not have the conditions to use VS. ^_^!)

Second, type conversion and marshaling

Since there are two platforms and two worlds of interoperability, the message between them must be converted to a type that the other can read, called "Marshal" or "marshaling". Data marshaling is an unusually complex process, and interested readers can search MSDN for a document that describes its rationale, "Marshaling Details." The following figure is the marshaling principle for COM Interop.

Fortunately, the Interop assembly mechanism of the. NET platform can help us to do some simple data encapsulation work and hide the complicated Marshal details. This makes it convenient for us to pass some simple data when invoking a COM server in a. NET client, but if the data being transferred is custom, it still requires manual Marshal. The principle of the mechanism describes the "COM wrapper" in MSDN.

The following figure, from MSDN Version 2003, describes what the. NET v1.1 will do to convert our data from one platform type to another, and any type that does not have an explicit identity in the table will be converted to the Int32 system type.

Well... It looks like a lot, but don't be happy too early, in the actual use only such as int and other relatively simple types to ensure that all kinds of flexible transfer mode without problems ... @_*. Note that the variant type of the COM side (which is also the recommended type for writing COM) will be converted to a specific type and encapsulated according to its VT value, so the COM side must set VT to be right, don't mess with it! In addition, it is best not to use or encapsulate as a custom type for specific types not given in the table.

For a detailed introduction to data type conversions, see "COM Data Types" in MSDN, and a description document for a custom type is "custom standard wrapper." If you want a. NET component to implement a callback interface or a connection point like a COM component, you need communication between the managed interface and the unmanaged implementation of the interface, and then you need to customize Marshal marshaling, which is the document that implements this feature, "Custom marshaling."