Guidelines for COM Interoperability from .NET (Update 1)

Guidelines for COM Interoperability from .NET (Update 1)

  • Comments 3

Sometime back I posted Guidelines for COM Interoperability from .NET where I enumerated several practices to follow when exposing types from your managed assemblies to COM. This update is to provide some additional information with the release of the Microsoft .NET Framework 2.0 as well as correct one statement I made with regard to inheritting interfaces when those interfaces are exposed either as automation interfaces (inheriting from IDispatch) or dual interfaces (inheriting both from IUnknown and IDispatch).

Previously I mentioned that you should declare class interfaces explicitly and implement them as the first interface on your class attributed with the ClassInterfaceAttribute with the value of ClassInterfaceType.None. In the .NET Framework 2.0 a new attribute was added to explicitly declare which interface is the default interface for the class since in some cases the provided compilers will generate interfaces in a different order and third-party compilers may not even honor the order in the first place. The ComDefaultInterfaceAttribute class should be declared for your implementation class and you should specify the type of the class interface. The class must still implement this interface. This is also necessary since the interface will always inherit from either IUnknown or IDispatch depending on the value you use for the InterfaceTypeAttribute attributed on the interface. See Inheritance, Aggregation, and Containment in the .NET Framework SDK for more information.

I also mentioned that you should implement new versions of interfaces that inherit from older interfaces. When exposing your interfaces with ComInterfaceType.InterfaceIsIDispatch or ComInterfaceType.InterfaceIsDual you should actually re-declare all previous members since many automation clients like Windows Script can only work with a single default dispatch interface. You should still implement the older versions of the interfaces but as explicit interface implementations.

Also note that there is a new namespace that you should use if you can base your development and deployment with .NET 2.0 as the minimal requirement. The System.Runtime.InteropServices.ComTypes namespace declares many interfaces commonly implemented by COM servers and used by COM clients. The interfaces in System.Runtime.InteropServices that begin with UCOMI* are obsolete and may be removed in future versions as well.

Leave a Comment
  • Please add 4 and 2 and type the answer here:
  • Post
  • For updates to this information, see http://blogs.msdn.com/heaths/articles/interopguide.aspx.
  • Hey, great article...me and a friend have hit one problem with COM Interop though...creating a CCW in 2.0 on x64 doesn't seem to work. We're having a hard time finding out the differences between running on x64 with .Net 2.0 64 Bit Edition and doing the same on a standard 32Bit OS using the 32bit version of .Net. In x64 ours COM tests always fail with a 'Component not Registered' error.

    Thanks,
       Kieron
  • Kieron, keep in mind that both 32- and 64-bit binaries are installed and work on a 64-bit Windows platform. If you've used the 32-bit regasm.exe to register an MSIL assembly (that is, an assembly that does not target a particular processor architecture) then running a 64-bit process won't find the 32-bit assembly registered; and vice versa. See my post at http://blogs.msdn.com/heaths/archive/2005/02/17/375816.aspx for more information.

    So, make sure you use the correct regasm.exe for the bitness you want to target, or run both the 32- and 64-bit regasm.exe to register an MSIL assembly (which is default when compiling for at least C# and VB.NET, BTW) so that both a 32- and 64-bit process can load the correct bitness of mscoree.dll, which then uses the type information to load your CCW.
Page 1 of 1 (3 items)