Exposing .NET Framework 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:
All managed types, methods, properties, fields, and events that you want to expose to COM must be public. Types must have a public default constructor, which is the only constructor that can be invoked through COM.
Custom attributes within managed code can enhance the interoperability of a component.
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.
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.
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.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.