This documentation is archived and is not being maintained.

Introduction to COM Interop 

The Component Object Model (COM) allows an object to expose its functionality to other components and to host applications. While COM objects have been fundamental to Windows programming for many years, applications designed for the common language runtime (CLR) offer many advantages.

.NET Framework applications will eventually replace those developed with COM. Until then, you may need to use or create COM objects with Visual Studio. Interoperability with COM, or COM interop, enables you to use existing COM objects while transitioning to the .NET Framework at your own pace.

By using the .NET Framework to create COM components, you can use registration-free COM interop. This lets you control which DLL version is activated when more than one version is installed on a computer, and lets end users use XCOPY or FTP to copy your application to an appropriate directory on their computer where it can be run. For more information, see Registration-Free COM Interop.

Managed Code and Data

Code developed for the .NET Framework is referred to as managed code, and contains metadata that is used by the common language runtime (CLR). Data used by .NET Framework applications is called managed data because the runtime manages data-related tasks such as allocating and reclaiming memory and performing type checking. By default, Visual Basic 2005 uses managed code and data, but you can access the unmanaged code and data of COM objects using interop assemblies (described later on this page).


An assembly is the primary building block of a .NET Framework application. It is a collection of functionality that is built, versioned, and deployed as a single implementation unit containing one or more files. Each assembly contains an assembly manifest.

Type Libraries and Assembly Manifests

Type libraries describe characteristics of COM objects, such as member names and data types. Assembly manifests perform the same function for .NET Framework applications. They include information about:

  • Assembly identity, version, culture, and digital signature

  • Files that make up the assembly implementation

  • Types and resources that make up the assembly, including those that are exported from it

  • Compile-time dependencies on other assemblies

  • Permissions required for the assembly to run properly

For more information on assemblies and assembly manifests, see Assemblies.

Importing and Exporting Type Libraries

Visual Studio contains a utility, Tlbimp, that lets you import information from a type library into a .NET Framework application. You can generate type libraries from assemblies by using the Tlbexp utility.

For information on Tlbimp and Tlbexp, see Type Library Importer (Tlbimp.exe) and Type Library Exporter (Tlbexp.exe).

Interop Assemblies

Interop assemblies are .NET Framework assemblies that act as a bridge between managed and unmanaged code, mapping COM object members to equivalent .NET Framework managed members. Interop assemblies created by Visual Basic 2005 handle many of the details of working with COM objects, such as interoperability marshaling.

Interoperability Marshaling

All .NET Framework applications share a set of common types that allow interoperability of objects, regardless of the programming language used. The parameters and return values of COM objects sometimes use data types that are different than those used in managed code. Interoperability marshaling is the process of packaging parameters and return values into equivalent data types as they move to and from COM objects. For more information, see Interop Marshaling Overview.

See Also