Using COM Types in Managed Code
COM types that are defined in an assembly are like any other managed types. Managed clients can create a new instance of a COM type in the usual way and obtain class information through metadata as they would for any other managed class. Method syntax can be inspected through an object viewer or obtained using reflection, just as it can with any other managed class. When the COM object returns a failure HRESULT, the .NET Framework client catches a corresponding exception.
There are two ways for your application to include the type information that enables interoperation with COM types:
Using embedded interop types: Beginning with the .NET Framework version 4, you can instruct the compiler to embed type information from an interop assembly into your executable. The compiler embeds only the type information that your application uses. You do not have to deploy the interop assembly with your application. This is the recommended technique.
Deploying interop assemblies: You can create a standard reference to an interop assembly. In this case, the interop assembly must be deployed with your application. If you employ this technique, and you are not using a private COM component, always reference the primary interop assembly (PIA) published by the author of the COM component you intend to incorporate in your managed code. For more information about producing and using primary interop assemblies, see Primary Interop Assemblies.
.gif "Note") Note |
|---|
When you use embedded interop types, you can embed them from the primary interop assembly published by the author of the COM component. However, you do not have to deploy the primary interop assembly with your application. |
Using embedded interop types reduces the size of your application, because most applications do not use all the features of a COM component. The compiler is very efficient when it embeds type information; if your application uses only some of the methods on a COM interface, the compiler does not embed the unused methods. When an application that has embedded type information interacts with another such application, or interacts with an application that uses a primary interop assembly, the common language runtime uses type equivalence rules to determine whether two types with the same name represent the same COM type.
Obtaining and releasing a reference to a running COM object is just like obtaining and releasing a reference to any other running managed object. When .NET Framework clients obtain and release a reference to a COM object, the runtime maintains the reference count on the COM object just as any other COM client would, and .NET Framework clients can behave as if the object were subject to garbage collection, just as they would for any other managed server object.
Visual Studio makes it easy to embed type information into an application or add-in. For examples, see Walkthrough: Embedding Type Information from Microsoft Office Assemblies (C# and Visual Basic) and Walkthrough: Embedding Types from Managed Assemblies (C# and Visual Basic).
For code samples that accompany the topics of this section, see COM Interop Sample: .NET Client and COM Server.
The rules for type equivalence are discussed in Type Equivalence and Embedded Interop Types. However, you do not have to know these rules to use COM objects.
See Also
Tasks
Walkthrough: Embedding Type Information from Microsoft Office Assemblies (C# and Visual Basic)
Walkthrough: Embedding Types from Managed Assemblies (C# and Visual Basic)
Concepts
Exposing COM Components to the .NET Framework
Inspecting an Assembly for COM Types
Calling Methods, Properties, and Events