I came across this interesting article: How I Came to Love COM Interoperability

Question

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?

Explanation / Answer

it takes away from the beauty of their .NET library

That author needs a wake-up slap to the face. For any professional project, the goal is to make working software that people want to use. Any kind of misguided ideals about beauty come long after that. If that's their only reasoning, the author has lost all credibility.

Being able to mark your classes as com-visible and being able to talk to your .NET code through COM is enormously useful. Discarding that great benefit to productivity for beauty is insane.

However, making things work with COM does require some trade-offs, requiring a no-arg constructor is one of them, and some of the other stuff you mentioned. If those are features you aren't using anyway, or it won't hurt you to not use them, then there is a lot of work to be saved by using the same class for COM and non com.

On the other hand, if your COM clients expect a dramatically different interface, has dependencies or other limitations that are nasty to deal with in your .NET classes, or you expect to be significantly changing your .NET classes and need to maintain COM backward-compatibility, then by all means create an Interop class to bridge that gap.

But don't think about "beauty". Being able to expose COM through .NET is meant to save you work. Don't create more work for yourself.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.