I came across this interesting article: How I Came to Love COM Interoperability on CodeProject, which got me thinking...
The author argues that they do not want any COM-ities in their .NET library because it takes away from the beauty of their .NET library. Instead, they'd rather write a separate Interop library that exposes their .NET library to COM. This Interop library would handle the fact that COM doesn't support Constructors with Parameters, Overloaded Methods, Generics, Inheritance, Static Methods, etc.
And while I think that is very novel, doesn't it just complect the project?
- Now you need to unit test your .NET library AND an Interop library.
- Now you need to spend time figuring out how to work around your beautiful .NET library and expose it to COM.
- You need to, effectively, double or triple your class count.
I can certainly understand if you need your library to support both COM and non-COM. However, if you only intend to use COM does this sort of design bring any benefits that I don't see? Do you only gain the benefits of the C# language?
Or, does it make versioning your library easier by providing you a wrapper? Does it make your Unit Tests run faster by not requiring the use of COM?