Разработка DLL на языке С++, страница 11

COM type libraries can be standalone .tlb files or they can be embedded in the resource section of a .dll or .exe file. Other sources of type-library information are .olb and .ocx files. After locating the type library containing the implementation of your target COM type, you can generate an assembly containing type metadata. The metadata can be generated in various ways. Usually it is generated from an existing type library that describes the types with a tool called Tlbimp.exe (Type Library Importer).

After the metadata is generated, it is saved as a typical .NET assembly. The assemblies are commonly called interop assemblies because they contain metadata for COM types but no code. Just like any other assembly, you can examine an interop assembly with tools like Ildasm.exe to browse the types defined in the assembly. There are a variety of tools that allow you to generate interop assemblies. The most common include the Microsoft Visual Studio® .NET IDE and the Tlbimp.exe utility.

When metadata is generated from a type library, the resulting assembly can be private and exposed only in the scope of an application or it can be shared by being placed in the global assembly cache. Private Interop Assemblies

The illustration shows an unsigned assembly to be used privately by Application1.exe and Application2.exe, which reside in separate application directories. The interop assembly, which is called ProductLib.dll in this example, is installed twice. Assemblies shared by multiple applications should be installed in a centralized repository called the global assembly cache. .NET clients can access the same copy of the interop assembly, which is signed and installed in the global assembly cache. A shared assembly has a strong name made up of the assembly name, version, culture, and the public key of the assembly publisher. TLBIMP includes the /keyfile, /publickey, and /keycontainer options for supplying information to generate strongly named assembly.

A shared interop assembly signed by the company that produced the original type library is called a primary interop assembly. An assembly signed by any other company or individual is called an alternate interop assembly. Primary interop assemblies (PIA) are provided by the same publisher as the type library that they describe and provide the official definitions of the types defined with that type library. Primary interop assemblies are always signed by their publisher to ensure uniqueness. A primary interop assembly is created from a type library by running TLBIMP with the /primary switch.

PIAs are important because they provide unique type identity. They distinguish the official type definitions from all other definitions provided by other interop assemblies, thereby ensuring type compatibility between applications that share the types defined in a PIA. When available, always use the primary interop assembly published by the author of the COM component you intend to incorporate in your managed code. Types in the primary interop assembly are imported for you and are ready to activate and call from managed code. Avoid using interop assemblies that are not primary interop assemblies.

Platform Invocation Services

Windows DLLs represent a special category of interoperability. Windows APIs do not use managed code, do not have built-in type libraries, and use data types that are different from those used with Visual Studio .NET. Because of these differences, and because Windows APIs are not COM objects, interoperability with Windows APIs and the .NET Platform is performed by using platform invoke. Platform invoke is a service that enables managed code to call unmanaged functions implemented in DLLs. You can use platform invoke in C# by applying the DllImport attribute to an empty procedure.