VB.NET 2005 Tutorials
Tutorials VB.NET 2005Working with Legacy Code and COM Components
Table of Contents
Working with Legacy Code and COM Components Working with Legacy Code and COM Components - Page 2 Working with Legacy Code and COM Components - Page 3Working with Legacy Code and COM Components
Working with Legacy Code - COM Components
In this tutorial you will learn to use COM Components, Understand Runtime Callable Wrappers, Type Library Importer (TLBIMP), Using COM Components Directly, Using COM+ Components and Creating Com+ Application.
Using COM Components
Component Object Model (COM) is a language-independent architecture that defines specifications for component interoperability. Each COM component is identified by a globally unique ID (GUID). It is a number that is unique across space and time. Implementation of COM is called ActiveX. COM objects can be compared with .NET components and ActiveX DLLs with Assemblies. This is because .NET components are more object-oriented.
.NET supports COM and ActiveX for backward compatibility. Let us see how this backward compatibility is achieved.
Understanding Runtime Callable Wrappers
Interoperability between COM objects that are run on unmanaged code and the .NET clients that run on managed code require a good deal of plumbing which is provided by the runtime callable wrapper (RCW). The CLR exposes the COM objects through RCW proxy. The RCW is primarily used to marshal calls between a .NET client and a COM object. The runtime creates RCW for each COM object, regardless of the number of references that exist on that object. Any number of managed clients can hold a reference to the COM objects. The runtime maintains a single RCW for each object.
The metadata derived from a type library can be used by the runtime to create both the COM object being called and a wrapper for that object. Thus each RCW maintains a cache of interface pointers on the COM object it wraps and releases its reference on the COM object when the RCW is no longer needed. So the RCW performs the garbage collection also.
We have already seen that RCW marshals’ data between managed and unmanaged code, on behalf of objects wrapped. It is particularly useful as the RCW marshals methods and method return values whenever the client and server have different representations of the data passed between them.
The wrapper enforces built-in marshaling rules. Thus it streamlines the communication between the server and client.
Using TLBIMP
The Type Library Importer converts the type definitions found within a COM type library into equivalent definitions in a CLR assembly. The TLBIMP.exe gives an output that is a binary file that contains runtime metadata for the types defined within original type library. The usage of the tool is given below:
Tlbimp tlbfile [options]
This file can be examined with Ildasm.exe
Some of the options that are used with TLBIMP are given below:
|
Option
Description
/asmversion:versionNumber
Specifies the version number of the assembly to produce. Specify versionNumber in the format major.minor.build.revision. |
|
/delaysign
Specifies to Tlbimp.exe to sign the resulting assembly with a strong name using delayed signing.
/help
Displays command syntax and options for the tool
/keycontainer:containername
Signs the resulting assembly with a strong name using the public/private key pair found in the key container specified by containername.
/keyfile:filename
Signs the resulting assembly with a strong name using the publisher's official public/private key pair found in filename.
/namespace:namespace
Specifies the namespace in which to produce the assembly.
/noclassmembers
Prevents Tlbimp.exe from adding members to classes.
/nologo
Suppresses the Microsoft startup banner display.
/out:filename
Specifies the name of the output file, assembly, and namespace in which to write the metadata definitions.
/primary
Produces a primary interop assembly for the specified type library.
/publickey:filename
Specifies the file containing the public key to use to sign the resulting assembly.
/reference:filename
Specifies the assembly file to use to resolve references to types defined outside the current type library
/silent
Suppresses the display of success messages.
/strictref
Does not import a type library if the tool cannot resolve all references within the current assembly, the assemblies specified with the /reference option, or registered primary interop assemblies (PIAs).
/strictref:nopia
Same as /strictref, but ignores PIAs.
/sysarray
Specifies to the tool to import a COM style SafeArray as a managed
/tlbreference:filename
Specifies the type library file to use to resolve type library references without consulting the registry.
/transform:transformName
Transforms metadata as specified by the transformName parameter.
/unsafe
Produces interfaces without .NET Framework security checks. Calling a method that is exposed in this way might pose a security risk. You should not use this option unless you are aware of the risks of exposing such code.
/verbose
Specifies verbose mode; displays additional information about the imported type library.
/?
Displays command syntax and options for the tool.
Tlbimp.exe performs conversion on an entire type library collectively. Tlbimp.exe also has options for supplying the information necessary to generate strongly named assemblies. A resource ID can also be appended to a type library file when importing from a module containing multiple type libraries. Tlbimp.exe is able to locate this file if it is in the current directory or if you specify the full path.
Next Page: Working with Legacy Code and COM Components - Page 2
|
