reasons for choosing com

i was wondering why one would choose Com as his software development "technology"

my first t开发者_开发百科hough is machine/programming _language independence

what's yours ?

COM is the de facto standard for automation and IPC on windows (though .Net has begun to shift the focus), thus there are areas you simply don't have (or had) a choice:

• Shell extensions
• ActiveX builds on COM
• Internet Explorer extensions
• extending MS Office applications
• Scriptability for JScript, VBScript, ... with one binary

Before the event of .Net nearly all automation of MS applications was through COM and quite some firms got on that train as well.

Also DCOM is, if you're willing to limit yourself to windows, a reliable and proven technology for distributed components.

The main strength of COM is that it's a widely applicable interop technology.

• COM is very well supported on Windows without having to install anything.
• It offers rich interop capabilities for various combinations of managed/unmanaged applications and applications in different languages - the client doesn't care how the server works and vice versa.
• If you already have a big unmanaged codebase (like for example we have millions lines of C++ code) and want to expose it's functionality to clients in a variety of languages COM will definitely be your choice - ATL makes creating COM servers quite easy and clients will be able to use without extra effort.
• Don't forget COM+ which is just great if you have a 32-bit unmanaged in-proc COM server and want to expose it to a 64-bit client - many times you only need several mouse clicks and don't need to code anything new at all.
• COM supports threading models (see this article for details) that lets you decide how much scalability you need from your COM component and how much you're willing to pay for that and no client will be able to misuse your component and get hurt because of concurrent access to data.

As gf said, people use it for automation. Furthermore, large parts of Windows are only accessible as COM objects. DirectX is an example.

My first thought is - don't!!! If you can stay away from COM/DCOM.

Of course if you need to integrate with legacy apps you will have no choice, but even then use COM only to cross managed/unmanaged boundaries.

If legacy compatibility is not an issue - stay managed. .NET has everything COM can offer anf then some. And the complexity and stability of the .NET code is nothing to compare with the equivalent COM code.

I've been working with Visual Studio integration for some time. Originally it was all COM, but MS slowly converts various pieces of it to managed. The new Editor framework based on MEF reduces the amount of necessary code by orders of magnitude. And no messing with registry. Such a relief.