Expose DOTNET components to COM
Mood
2002-4-23
Article Type: in-depth
Difficult Level: 6/9
Version: 2.32
The topic between COM and DOTNET seems to always not finish, as long as COM still exists, you use DOTNET, then there are always interesting things that make you encounter. This is unlike the male and female protagonist, but it is like a debug and the wrong process, you must be very clear that it is in COM or DOTNET, in fact, sometimes you will ignore a more important Factors: People's factors - Everyone will make mistakes :)
The interactivity call in the DOTNET system can be divided into two levels: one level is about the original platform call; one is about the call of the COM object (seemed that the microsoft division DLL is COM before COM, in addition to COM, based on Win32S The C / C DLL, the microsoft divided DLL after DOTNET is called by DOTNET. In addition to the Managed DLL remains non-managed dll), for the first level, Microsoft recommends using P / Invoke, in fact it can Work is good, but this is also a single-directional, namely DOTNET (CLR) calling the platform's DLL (Win32S); in the opposite direction, the problem of calling DOTNET components in the original DLL, Microsoft has nothing to do too urgent needs. Developers outside the Widnows platform seem to be more interested in this issue (they don't have COM). For P / INVOKE, Microsoft uses his rich experience on the compiler to solve this problem very well after experiencing VJ , how to use attributes to tell the compiler to convert these parameters, because the call is finally on the stack (No matter where the stack is shared), just guarantee that the type translation and conversion on the stack when the call is called, it doesn't matter if it is more than managed or not. Don Box's article has announced a list of ISOMORPHIC AND NONISOMORPHIC TYPES listing the DOTNET data type and the type comparisons in the platform DLL. Almost all types and DOTNET existing types in almost Win32S DLL are ISOMORPHIC, which means that these types calls do not have been converted if they happen to call and the called shared stack. The remaining is some of the few types (Wchar and LPST), Interface, BSTR, Variant, and SafeArray (see if COM is related, and finally understand the cause of Struct in C # and the entire CLR: Struct is also ISOMORPHIC, those designers of Microsoft really worry about Haha)
The remaining is interactive with COM. In fact, the problem has evolved to a reference to a DOTNET component to convert to COM's reference or the opposite issue. This involves the reference count and life cycle of the object, far from the stack to solve. Microsoft gives a clear solution: as the mscoree.dll, when a CLR object is referenced by the mscoree boundary (then there must be a COM sky), one guarantees that this CLR object can be automatically established by COM. (COM-CALLABLE WRAPPER); the same COM object application enters the boundary of MSCOREE (then there must be a DOTNET sky), so there is also a guarantee that this COM object can be automatically established by DOTNET calls (Runtime-Callable Wrapper). This agent / stub game COM era is also rich and colorful, now the same, but everyone has Mscoree as a world, both parties have a reference count, life cycle, event, serialization, synchronization, etc. Realization, in fact, the COM object is not taken and control by DOTNET, and the DOTNET object is not taken and control by COM, and everyone exchanges data and exposes interfaces and functions. Go back and see that this seems to go back to the first level, and now the call is a superchard of P / Invoke (where the location is transferred from the shared stack to the agent and the stub) is the so-called concept, but in fact actual In the application and operation, we see what borders do not have, what agent / stub. It is easier to cause the DOTNET to call COM components: vs.NET IDE has almost packaged everything. But the anti-direction process allows you to have a fear of old-fashioned development environments (good way is Microsoft to release a sp7 haha for the current VS98. Below we will go to some of the more typical issues, for example, how to expose a DOTNET component to the VB6 environment. Compared with the first P / Invoke, I think there is not much content, this is the only skill is your observation and practical ability, collecting experts or masters P / Invoke statement is the most effective, practical is testing these The function declaration is correct, the most important thing is that there are too many of these Win's API; we will see some related skills and information, these are about COM and DOTNET interaction, I think this is our application DOTNET process There will be more problems that will encounter, especially when migrating applications and switching development environments.
The first question is how to display the DOTNET component to COM, which we want the previous VB, ASP, or other language to directly use the DOTNET component and it. Here you must complain that some DOTNET Beta2 works or articles, if you still follow the above, you will often hear such questions: Why don't you see a method in the VB object browser?
It is often seen that they see such a pair of pictures, but there is a class name on the left, but there is no member function on the right to call.
In the Comvisible project in the file, you will see the entire code process, here we just tell some places that are easy to ignore, the following is a possible Checklist:
1. Do you quote System.Runtime.InterOpServices and System.Reflection
2. Whether the component is strong, if it is not best to use SN -K to name the component.
3. Whether the exposed class and interface have already used the Progid property.
4. Whether the exposed Class and Interface have used the GuidAttribute property and the fixed GUID.
5. Whether the ClassInterFacettribute property is used and the correct value is set.
6. Whether to register the correct settings in VS.NET or in manual way.
7. Whether the TLB file that is needed after binding, if you already, check if its content is in line with your needs.
For my suggestions for 1 to 4 points, it is best to have, although some they are not necessarily; for 5 points, it is most important to ignore.
ClassInterfacettribute has three types of parameters:
Autodispatch
Indicates that Class is only supported by COM consumers, which automatically generates a DISPINTERFACE when the COM consumer request, but the type information of this interface will not be described in the type library generated by TLBexp. This is the default option of ClassInterfaceAttribute.
Autodual
Indicates that a dual interface class is automatically generated and exposed to COM, and the type of interface information will include information of the class interface, but this option is not a suggested option. Microsoft Warnings You have to be careful about version compatibility issues.
None
Indicates that no class interface is generated for classes. This is a suggested option.
If this description is not very clear, you will see the TLB file description of the TLB files that I have in this three parameters, maybe you will be clear.
The type library description generated by the Autodual parameter: CoClass DotnetClass {[Default] interface_dotnetclass; interface _object;
[ODL, UUID (1EA7C0BF-0562-3D1E-A6C3-89CF63F040F6), Hidden, Dual, Nonextensible, Oleautomation, Custom (0F21F359-AB84-41E8-9A78-36D110E6D2F9, COMVISIBLE.DOTNETCLASS)
] Interface _dotNETClass: IDispatch {[id (00000000), propget, custom (54FC8F55-38DE-4703-9C4E-250351302B1C, 1)] HRESULT ToString ([out, retval] BSTR * pRetVal); [id (0x60020001)] HRESULT Equals ([In] variant obj, [out, retval] variant_bool * pretval); [ID (0x60020002)] HRESULT GETHASHCODE ([OUT, RETVAL] long * Pretval; [ID (0x60020003)] HRESULT GETTYPE ([OUT, RETVAL] _Type ** PRETVAL); [Id (0x60020004)] HRESULT ADD ([in] long x, [in] long Y, [out, retval] long * pretval); [ID (0x60020005)] HRESULT ADDEX ([in] long X, [in] long y, [in] long z, [out, return] long * pretval); [ID (0x60020006)] HRESULT HELLO ([OUT, RETVAL] BSTR * PRETVAL);}; Special:
This article original, 9CBS signature start, all text and photo copyright. Do not propagate, reprint, or adaptation without authorization.
If you have any questions or suggestions, please email new2001@msn.com
