Expose DOTNET components to COM
The god of the small gas 2002-4-23
Article Type: In-Depth Difficult Level: 6/9 Version: 2.32
The type library description generated by the AutodisPatch parameter:
Coclass dotnetclass {[default] interface _dotnetClass; interface_Object;
[ODL, UUID (BCE3DFCD-F8F6-32F6-BB38-6F4928090805), Hidden, Dual, Oleautomation, Custom (0F21F359-AB84-41E8-9A78-36D110E6D2F9, COMVISible.dotnetClass)
] Interface _dotnetclass: idispatch {}; NONE parameter generated type library description: coclass dotnetClass {[default] interface _object;};
If the customer of the DOTNET component is a VB or a Script environment that requires a dual interface, then our best choice is: Autodual.
Otherwise, we may really happen in VB.
As for the 6th point, it is registered. If you don't set it automatically in VS.NET, then this DOTNET is to be exposed to COM, then you need to register manually. You can click on the item in the Solution Explorer in vs.net, then the properties in right click open this switch on the configuration page. As shown below
I suggest you complete all encodes to open this switch before the first test. This switch is basically the same as your two manual functions, one is the REGASM component.dll and TLBEXP component name / out: TLB file name. If the automatic mode VS.NET will automatically unregaSM and register again, we will not compile a new GUID number to make you confuse your registry without compiling a new GUID number.
However, if we can change our original habits, we should use Interface instead of creating a Class or component directly in VB like it. This way is more elegant and robust:
[GuidAttribute ( "ATC869A7-F101-4e7c-B062-CE56FDA5F678")] public interface: IdotNETClass {public int Add (int x, int y); public int AddEx (intx, int y, int z); public string Hello () }
[GUIDATTRIBUTE ("08C869A7-F101-4E7C-B062-CE56FDA5F352")] Public Class DotnetClass: idotnetClass {...............
The interface followed by the precise definition is to make your companions' design and code habits, so that all the tools do not have to speculate the definition of the class. For VS.NETs, there are some ideas that have some perceived features, do not have much attribute that it can understand your intentions.
Here are some of the support properties of common COM interoperability, these attributes are CLRs as a COM object, exposed to the non-hosting domain. Most of this information can be found in System.Runtime.InteropServices.
Attribute example Adaptation Scope Description COMVISIBLE
[Comvisible (FALSE)] Class, Structure, Interface, Entrust, Accessories Decision Generated CLR Public Type DISPID [Dispid (3)] method in the generated type library, the property determines DISPID for iDispatch interface to access Progid
[ProgID ("DOTNET.C"] Progid GUID used by class classes
[GUIDATTRIBUTE ("XXX")] class, interface, module structure, enumeration delegate specified COM GUID. Be careful and guid type Conflict InterfaType
[InterfaType (CominterFactype.IterFaceISDual) Interface Specify Type Library Generates any COM interface type, such as: iUnknown ComregisterFunction
[ComunRegisterFunction ()] Method requests REGASM.EXE to perform a method HasDefaultInterface
MSDN HELP class specifies the default interface Noidispatch
MSDN HELP class indicator from IUNKNOWN MARSHALAS
Marshalas ()
Property definition column
I don't fully think that "DOTNET can completely replace the previous COM programming method, but can not replace COM " This conclusion must be correct or such an era, but it is indeed a very good compatibility of COM interoperability provided by DOTNET. And interoperability; if you used VB, VC for COM development, then you can still do the same thing on the DOTNET platform, some subtle changes are, after experiencing a practical curve, you will find DOTNET It is more convenient and saved under the platform. Of course, you must ensure that you are not very mindful, because this interaction inevitable needs need to be code in some performance.
Ok, I will raise such an example: Before the DotNet we developed more than the way to use COM, since the BizTalk Server 2002 Toolkit for Microsoft.Net is released, you can do more work with DOTNET. For example, we often program the development of Application Integration Component (AIC), which must be required to register with a specific Catalog ID of the registry with a specific Catalog ID of the registry, using VC ATL, becoming the ATL Macro However, other ways, almost require manual production and completion of registration steps, and Microost finals tell you that the simplest way to AIC components is to install them into COM , which is not only registered but also improves performance. But if we know the above properties Using ComregIsterFunction / ComunRegisterFunction, you can tell REGASM.EXE to execute a certain way to perform a certain registration, the maximum function of the component. In an incidentally, we can see the last plus such code when we implement the original class:
[ComRegisterFunction ()] public static void RegisterFunction (Type t) {try {// Implements CATID_BIZTALK_COMPONENT category Registry.ClassesRoot.CreateSubKey ( "CLSID // {" t.GUID.ToString (). ToUpper () "} // Implemented Categories // {5C6C30E7-C66D-40E3-889D-08C5C3099E52} "); // Implements CATID_BIZTALK_CUSTOM_PROCESS category Registry.ClassesRoot.CreateSubKey (" CLSID // { ". t.GUID.ToString () ToUpper () "} //MPLEMENTED CATEGORIES / / {BD193E1D-D7DC-4B7C-B9D2-92AE0344C836} ");} Catch (Exception E) {throw new Exception (E.MESSAGE, E);}}
REGASM will perform this code to complete the entry of special Catalog when registering.
Similar situations such as SQL Server, Visio, Office plug-in, smart tags, and even AutoCAD for Win, etc. I have supported a famous application development program that supports COM interfaces. You can apply DOTNET interoperability to complete the previous COM environment. Work, and work in a DotNET environment, you can get some benefits that have not been obtained from the entire DOTNET framework, such as: namespace, components, name, multi-version, key, self-description component, thread mode, etc. It is the most pleasant :) When you span why you want to use the DOTNET component, put the focus in how to expose the DOTNET component to COM and do this, I think this kind of thinking and practice itself will give You brings a lot of different experiences and benefits.
The above is simple to examine some of the most basic and common methods of DOTNET and interoperability. In the process of using DOTNET and to DOTNET migration, we will find that for DOTNET calls COM components or COM applications, call DOTNET components will gradually decrease. However, it may still exist for a long time. More and more situations are DOTNET's "managed" environment for DOTNET, interoperability is just for the best compatibility, but if you like it very much, it is difficult to forget such a late binding. The charming characteristics will be necessary to fully use this interoperability. Good interoperability allows us to have more choices, you can also keep our favorite features, half COM half DOTNET architecture to ensure smoothing. But as described above, perhaps the interoperability in a certain situation may become your unique choice or a way to pass :)
Related files Download: [comVisible.zip 29k]
especially:
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
