Exposing .NET components to COM
Writing a .NET type and consuming that type from unmanaged code are distinct activities for developers. This section describes several tips for writing managed code that interoperates with COM clients:
Qualifying .NET types for interoperation.
All managed types, methods, properties, fields, and events that you want to expose to COM must be public. Types must have a public parameterless constructor, which is the only constructor that can be invoked through COM.
-
Custom attributes within managed code can enhance the interoperability of a component.
Packaging an assembly for COM.
COM developers might require that you summarize the steps involved in referencing and deploying your assemblies.
Additionally, this section identifies the tasks related to consuming a managed type from a COM client.
To consume a managed type from COM
-
Types in an assembly (and type libraries) must be registered at design time. If an installer does not register the assembly, instruct COM developers to use Regasm.exe.
Reference .NET types from COM.
COM developers can reference types in an assembly using the same tools and techniques they use today.
-
COM developers can call methods on the .NET object the same way they call methods on any unmanaged type. For example, the COM CoCreateInstance API activates .NET objects.
Deploy an application for COM access.
A strong-named assembly can be installed in the global assembly cache and requires a signature from its publisher. Assemblies that are not strong named must be installed in the application directory of the client.
See also
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for