COM Interoperability in .NET Framework Applications (Visual Basic)
When you want to use COM objects and .NET Framework objects in the same application, you need to address the differences in how the objects exist in memory. A .NET Framework object is located in managed memory—the memory controlled by the common language runtime—and may be moved by the runtime as needed. A COM object is located in unmanaged memory and is not expected to move to another memory location. Visual Studio and the .NET Framework provide tools to control the interaction of these managed and unmanaged components. For more information about managed code, see Common Language Runtime (CLR).
In addition to using COM objects in .NET applications, you may also want to use Visual Basic to develop objects accessible from unmanaged code through COM.
The links on this page provide details on the interactions between COM and .NET Framework objects.
Related Sections
COM Interop (Visual Basic)
Provides links to topics covering COM interoperability in Visual Basic, including COM objects, ActiveX controls, Win32 DLLs, managed objects, and inheritance of COM objects.COM Interop Wrapper Error
Describes the consequences and options if the project system cannot create a COM interoperability wrapper for a particular component.Interoperating with Unmanaged Code
Briefly describes some of the interaction issues between managed and unmanaged code, and provides links for further study.COM Wrappers
Discusses runtime callable wrappers, which allow managed code to call COM methods, and COM callable wrappers, which allow COM clients to call .NET object methods.Advanced COM Interoperability
Provides links to topics covering COM interoperability with respect to wrappers, exceptions, inheritance, threading, events, conversions, and marshaling.Tlbimp.exe (Type Library Importer)
Discusses the tool you can use to convert the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly.