Should I use COM? (and would using COM require a séance?)

  • Article

Reader Andre poses a great question about the use of COM for a new project:

Steve, I would like to hear your opinion whether or not to use COM for the development of a new component based application.

There is a large native C/C++ code base, where porting to managed code is not an option because it is also used on other OS and even microcontrollers.

The first option would be to use COM, so the components can be written entirely in native C++, any .NET language and even Java with JCOM.

The second option would be to use the .NET component model and write some components with C# and the other ones with C++/CLI.

Office 2007 and Vista introduces new COM interfaces, so all the talk about COM beeing dead doesn't seem to be true.

I'll just be direct here: if you need a native code component model, then COM is a fine choice.  Yes, yes, COM has warts and all, but by the same token, COM's warts are generally well-known and well-understood.  Rumors of COM's death have been pretty widely exaggerated.  As you point out, even the Windows Vista folks have written a bunch of new COM code.  Most notably, much of the new shell functionality (search & organize, live icons, etc.) is built using COM-based API's.

Of course, that's not to say that if you have native C++ code that you wish to wrap with a component model that COM is your only choice.  C++/CLI is really good at wrapping existing native code with a managed code API accessible by other .NET languages.

It really comes down to what kind of API you want to create.  A COM API would probably perform a bit better, particularly if the API is chatty, but COM is more complex and lacks .NET's nice metadata and security.  A .NET API would provide easy access to all the .NET languages and would likely make for a simpler programming model.

On to the broader question of when does a technology like COM die? The answer to this question of course has many facets, but here are a couple of major factors:

  • A technology dies when people stop using it.  Without a critical mass of users, there is no community for a technology and no business case for a company to support it.
  • A technology may also die when a better solution comes along that solves most the same problems as the original technology with a small number of drawbacks.

By these measures, COM is still very much alive and well; COM still has lots of users and it continues to fill a technological niche that .NET does not.  Of course, there are some scenarios for which .NET has supplanted COM (visual components for form-based apps, for example), but it still has value in native code / low-dependency scenarios.