Using COM Components in .NET
This Article will help you in understanding the Inter operation between .NET Environment and COM components (Which are nothing but Win32 Dynamic Linked Library and ActiveX controls.
That's .dll and .ocx files).
Consider this, If I have few COM components which includes DLLs and ActiveX components as well, and now time has come to upgrade the application functionality and UI things, Also there is requirement of Application availability through Web. So what I have decided to write some part of the application in .NET so that Web Deployment and the registration problems of DLL and ActiveX problems will be removed.
In above scenario, either I can write the whole new application which is truly .NET Framework based, or I can make use of the available functionality of the business logic in newly developed Web Application and Desktop application. Yes, I am talking about the COM-.NET Inter Operation, the way by which I we can talk with COM components and vice versa.
Let's start digging and find out what exactly the COM Inter Op is and what are the different ways by which we can achieve it.
What Exactly the DLLs and OCX files are?
A Dynamic Linked Library (DLL) is a file code containing functions that can be called from other executable code (either an application or another DLL). Programmers use DLLs to provide code that they can reuse and ship with the product and to distribute. Unlike an executable (EXE) file, a DLL cannot be directly run. DLLs must be called from other code that is already executing.
A DLL is a file indicated by the extension DLL in its name.
e.g- > kernell32.dll, msvbvm60.dll, msvcrt32.dll
In Simple words DLL is a file which contains function calls available for the outside world and outside world can make use of these function calls. Here outside world is nothing but, Another DLL and or an Application.
On the other hand OCX or simply ActiveX components are the components which (Dlls and Ocx are together called as ActiveX components). In next section we will see what exactly the ActiveX Components are.
An ActiveX control is really just another term for "OLE Object" or, more specifically, "Component Object Model (COM) Object." In other words, a control, at the very least, is some COM object that supports the IUnknown interface and is also self-registering. Through QueryInterface a container can manage the lifetime of the control, as well as dynamically discover the full extent of a control's functionality based on the available interfaces. This allows a control to implement as little functionality as it needs to, instead of supporting a large number of interfaces that actually don't do anything. In short, this minimal requirement for nothing more than IUnknown allows any control to be as lightweight as it can. Other than IUnknown and self-registration, there are no other requirements for a control. There are, however, conventions that should be followed about what the support of an interface means in terms of functionality provided to the container by the control. This section describes what it means for a control to actually support an interface, as well as methods, properties, and events that a control should provide as a baseline if it has occasion to support methods, properties, and events.
I think, this is enough to see what and how exactly we can interact with COM from within the .NET and vice versa.
Runtime Callable Wrappers
As discussed in background, it is more likely that.NET Application will have to interoperate with COM, we will first find out how we can achieve that. A .NET application access COM through Runtime callable wrappers or RCW. RCW wraps COM object and acts as a bridge between COM and .NET Runtime, and acts as if RCW is a Native Object.
We can generate RCW, by one of the two ways. First, using Visual Studio.NET, In Microsoft Visual Studio.NET, right-click on the References section of your Project, (If you are unable to view the References section under project, then click on "Show All Files" icon on Solution Explorer window, by default References section is hidden in Visual Studio 2005). Select Add Reference, you will see the dialog box, (Fig.1) here you can browse for COM component that you want add into your project as a reference. Select the desired file and click on add, Visual Studio.NET will create RCW and will add it as a reference in the project.
<formulas /></formulas />
If you're not using Microsoft Visual Studio.NET Environment, there is another way bu which you can create RCW. When you install .NET Framework SDK (VS.NET), there are certain set of tools, gets installed on the system. Out of those tools, one tools called TlbImp.exe (Type Lib Importer Utility), which is useful for creating RCW or Runtime callable Wrappers. Let's find out how we can actually import COM as reference or how we can create RCW.
(Note: To run this example make sure you have Library path set in your system variables.)
For example you want to add COMDemo.dll Com component from command line as a reference, then on the command line you type following.
C:\> tlbimp comdemo.dll
It will create RCW in the directory you've specified; now you can refer RCW in your project by importing or creating objects.
COM Callable Wrappers
Suppose, on the other hand, that you have a client that already talks with COM and now you want to make it use a .NET object instead. This is a somewhat less common scenario than the reverse situation because it presupposes new COM development in a .NET world. But I can easily see it occurring if you have an existing COM client that uses 10 COM objects and you now want to add an additional set of functionality that exists only as a .NET object. The .NET Framework supports this situation as well, via a COM-callable wrapper (CCW).
Here exactly the reverse things happens, CCW wraps .NET Objects and makes it available for the COM interaction, it acts as if it is a COM Component to the Other COM objects and or application outside of the .NET world. Now there are some rules that we need to follow to make it happen and work properly. First, .NET component which is required to be exposed to the COM, must have signed strong name, otherwise CLR will not recognize it. Second, it must reside in local machines Global Assembly Cache (GAC). If you want your CCW to be available for the other applications also, then it must reside in GAC, if not (which is less common) then it must present in applications directory (then it will act as Private assembly and is only available to that particular application). As the matter of fact COM component does not know how to pass the parameters while creating an object, .NET component, which is to be exposed must have a default constructor (a constructor without parameter list).
In order to for COM components to find .NET Object, you also need to make registry entry for that .NET component. This we can do using a tool call RegAsm.exe, which is again available when you install .NET SDK. To register type following on the command line.
C:\> regasm <name of the .NET component>
After registration is successful, COM Components can take the advantages of .NET objects.
In next article we will look more deeply, how we can create .NET Components for COM interaction and how we can control the exposure.
Here is something useful which you can take advantage of.
1) Registering DLL,OCX using Win32 command line. In Start-> Run Type following if you want to register any dll or ocx file. Regsvr32 "path"\xyz.dll or Regsvr32 /i path"\xyz.dll
2) To un registering the registered path from the windows registry you type Regsvr32 /u path"\xyz.dll
[Note: This registration method is only application for COM components]