. NET application tips: Use of unmanaged COM components

As we all know, ASP.net is created based on the common language runtime, the so-called managed execution environment. The generated code is called managed code. The compiler is able to generate metadata information from the description of the source code, and the runtime obtains the managed code information from the metadata. And the components we write are typically created in an unmanaged environment, and these components often do not contain metadata information, so how do we use these metadata information in managed code?

In order to use unmanaged code in a managed environment, we first have to manually generate metadata information for these existing components. There must be a tool to generate metadata. The ability to get metadata from somewhere. The source of this metadata is the type library, in fact, all of the components today have a type library.

To illustrate how to generate metadata information, let's take the Microsoft Agent component as an example. This component is similar to a small office assistant that can perform a variety of personalized actions and support speech recognition and speech synthesis. The general operating system installs this component by default, and users should not worry about not having this component. If your system deletes this component, you can go to http://microsoft.com/msagent/downloads.htm to download it. The following is an introduction to using unmanaged COM components in asp.net.

1, first is to create metadata

The Microsoft agent control defaults to being installed in the%systemroot%\msagent\ directory, first running the Visual Studio.NET command Prompt (Command Prompt) menu item in the Start menu. Execute the following command in this directory.

TlbImp Agentctl.dll/out:agentctl_proxy.dll

With this command we can create a proxy file Agentctl_proxy.dll that contains metadata information. Note that this is not a true dynamic connection library file, but rather an assembly file (Assembly), which is the proxy for our unmanaged COM component.

can also be passed. NET Framework, the utility AxImp.exe is created, the command line is as follows, so it generates two files, as shown in the following illustration: Note that AgentObjects.dll and Agentctl_proxy.dll files are identical files.

C:\Program Files\Microsoft Visual Studio 9.0\vc>aximp%systemroot%\msagent\agentctl.dll

2, installed in the ASP.net

There are two ways to install Meta data files into a asp.net environment:

One is to copy the files to the application's Bin directory.

The second is to copy it to the ASP.net directory.

The second approach has a flaw where you have to insert a @assembly statement in each asp.net page that uses the component. This can be avoided by saving to the bin directory. Assembly will be loaded into all asp.net pages of the application. So we'd better put it in the bin directory.

3. Il disassembly (disassembler)

Now it's almost time for most VB or VBScript programmers to get headaches, and we're going to use an disassembler to produce some important information.

Assembly namespace (using @Import statement)

The exact class name (this may be very different from the ASP!)

Data types of methods and properties

The exact spelling of methods and properties. Note that Bodytext and Bodytext are two completely different variables in C #.

Generating the above information requires the use of the Il (intermediate Language) Disassembler intermediate Language disassembler, and you can type Ildasm.exe to start the tool after the metadata is generated. You can then use file Open to select the appropriate files, and the results displayed are very similar to the results of the ole/com viewer.

Note that the generated assembly file is different, the name of the namespace is not the same, in asp.net pages often need to use @Import import namespaces, but their classes, properties, methods are the same. For ASP.net programmers, the entire blue symbol is important because they represent a class or an interface. If we expand on these classes or interfaces, we get a list of properties and methods.

All of the methods we see have an exact data type description. The first is the method name, followed by the return value type parentheses, which are the parameters required by the method.

When we talk about attributes using the get_ and set_ methods, VBScript programmers may confused, and we know that each attribute actually corresponds to a private member of the class, and that the read-write of the attribute is implemented through both functions.

Each property has a red tag next to it, and by double-clicking the property, we can get the definition of the property, and we can see that the property can be a getting, Set, or Get/set.

4, the use of components

When we understand the metadata, the rest of the work is how to use this component in ASP.net, and here is a section of code that uses msagent:

<% @Page language= "C #"%>

<% @Import namespace= "Agentobjects"%>

<% axagentobjects.axagent axagent=new axagentobjects.axagent ();

Iagentctlcharacterex Character;

AxAgent.Characters.Load ("Genie", (object) Genie. ACS ");

Character = axagent.characters["Genie"];

Character.languageid = 0x409;

Display the character. Character.show (NULL);

Character.speak ("Hello World", null);

Response.Write (Character.name);

Character.play ("Wave");

Character.play ("Hide");

%>

When you import a type library, we then create an instance of the class, and the rest of the usage is basically the same as the ASP application component.

All COM components call methods that are essentially the same, just as adding a COM component reference to a managed application (C #, Visual Basic.NET), and then the system to generate an encapsulation for these unmanaged code, is actually performing the steps above, that is, importing the type library. In fact, this approach can be used in all managed applications, including managed C + + code, C #, Visual Basic.NET environments, the interoperability of the. NET Framework protects the existing investments of component developers, and provides a way of thinking about our managed programming. That is, we can encapsulate many of the features that are difficult to implement or implement with managed code (such as the physical sector of the floppy disk drive via API function calls) into an unmanaged COM component, which is indirectly implemented through component calls.