This topic has not yet been rated - Rate this topic

Qualifying .NET Types for Interoperation

If you intend to expose types in an assembly to COM applications, consider the requirements of COM interop at design time. Managed types (class, interface, structure, and enumeration) seamlessly integrate with COM types when you adhere to the following guidelines:

  • Classes should implement interfaces explicitly.

    Although COM interop provides a mechanism to automatically generate an interface containing all members of the class and the members of its base class, it is far better to provide explicit interfaces. The automatically generated interface is called the class interface. For guidelines, see Introducing the Class Interface.

    You can use Visual Basic 2005, C#, and C++ to incorporate interface definitions in your code, instead of having to use Interface Definition Language (IDL) or its equivalent. For syntax details, see your language documentation. 

  • Managed types must be public.

    Only public types in an assembly are registered and exported to the type library. As a result, only public types are visible to COM.

    Managed types expose features to other managed code that might not be exposed to COM. For instance, parameterized constructors, static methods, and constant fields are not exposed to COM clients. Further, as the runtime marshals data in and out of a type, the data might be copied or transformed.

  • Methods, properties, fields, and events must be public.

    Members of public types must also be public if they are to be visible to COM. You can restrict the visibility of an assembly, a public type, or public members of a public type by applying the ComVisibleAttribute. By default, all public types and members are visible.

  • Types must have a public default constructor to be activated from COM.

    Managed, public types are visible to COM. However, without a public default constructor (a constructor with no arguments), COM clients cannot create the type. COM clients can still use the type if it is activated by some other means.

  • Types cannot be abstract.

    Neither COM clients nor .NET clients can create abstract types.

When exported to COM, the inheritance hierarchy of a managed type is flattened. Versioning also differs between managed and unmanaged environments. Types exposed to COM do not have the same versioning characteristics as other managed types.

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Protected and Private members are OK if they are not supposed to be visible to COM
The bullet point "Methods, properties, fields, and events must be public" is a bit misleading and too general. In the lines following the bullet point it is described that those members that are to be visible to COM must be public, which is correct. This documentation has probably led to the author of the MCTS Self paced training kit for exam 70-536 (2nd edition) to make the statement that all fields must be public, even though they are not accessed directly by COM applications, which is incorrect (p624), and that the only way to make fields invisible to COM is to use the ComVisible(false) attribute, which is incorrect again.
If a private field of a .Net class is only used inside the .Net class and is not accessed by the COM application, then there is no need to make it public.
Protected and Private members are OK if they are not supposed to be visible to COM
The bullet point "Methods, properties, fields, and events must be public" is a bit misleading and too general. In the lines following the bullet point it is described that those members that are to be visible to COM must be public, which is correct. This documentation has probably led to the author of the MCTS Self paced training kit for exam 70-536 (2nd edition) to make the statement that all fields must be public, even though they are not accessed directly by COM applications, which is incorrect (p624), and that the only way to make fields invisible to COM is to use the ComVisible(false) attribute, which is incorrect again.
If a private field of a .Net class is only used inside the .Net class and is not accessed by the COM application, then there is no need to make it public.