Is COM dead ???

Question

What are profound advantages that one get when using COM for developing components over the WCF ?? Is there anything that can be done with COM and not with WCF ??

Answer 1

No it's not dead yet, but it's on its death-bed, that's for sure. You see there's still to many legacy systems that use/require COM, that assures us it'll be with us for a few more years, but not in the long-run.

As for WCF, there might be some edge cases of stuff COM can do, and WCF can't, but more importantly, and related to legacy stuff, is that there are COM bindings for almost every language you can put on a windows stack, but the WCF bindings are not ready yet for everyone (languages)

Answer 2

Depends on how deep into the system you want to dig. COM will never 'die', same as unmanaged languages never will.

To make long story short, if you develop desktop applications for Vista+, you probably won't need to bother using COM anymore.

Answer 3

If I am not mistaken, .NET is intended to replace tech like COM and WFC. Is there a reason (other than legacy code) that one would chose COM or WFC over .NET?

Answer 4

I don't think COM is dead. If you look at the Vista, it uses so much of COM architecture/technology. Every thing in Vista is a COM Dll/Exe. I feel when compared to XP, Vista uses so much of COM.

If we want to extend any thing in Vista we have to implement interfaces using COM.

Answer 5

There are several distinct aspects:

1. Components that will run on and interact with multiple computers (as services)
2. Components that only run locally, and interact with components implemented by multiple vendors through an ABI.
3. Components that are authored by a single vendor without any need to interact with third-party components.
4. Components from multiple vendors that are available in source code, that can be compiled into a single application.

(ABI = application binary interface. COM is an example of an ABI.)

For aspect 1, COM is pretty much dead.

Aspect 2 still requires COM, and will continue to be. Windows Imaging Component is a great example of such extensibility allowing anyone to implement new image codecs. .Net is a strong contender in this aspect.

For aspect 3, COM is still worth considering, but this is a decision to be made for each software vendor. Components developer for in-house use may one day be sold as a product. .Net seems to be a good choice here as well.

For aspect 4, one can simply adapt and combine the source codes from many open-source projects. There is no need for COM, or any ABI.

COM as an unmanaged ABI is, unfortunately, difficult to defend against bugs because the code and data are in the same memory space, and the stack is used for both data and execution call stack. Any exploitable hole in one COM component can be used to cause instability in any other COM components loaded into the same address space.