Has .NET made raw COM and DCOM programming redundant ?

Question

Has the introduction of the .net framework made raw programming in COM and DCOM redundant ?

(Except for using some COM+ services, e.g. for transaction management through the System.EnterpriseServices namespace)

Answer 1

Not yet, but I'd say in the long term, it aims to. Obviously there will always be a place for the lower levels, but from what I understand of Microsoft's strategy, the move is towards replacing as much with managed code as possible.

Answer 2

.NET has been deliberately designed to replace COM (and, consequently, DLL Hell) so while .NET applications still can access COM components, all new development are encouraged to move to .NET except if you have a very good reason to stick with COM.

Answer 3

Not yet, because the OS is still unmanaged.

If MS finally do what their labs have been talking about for years and produce a fully managed OS then it will.

That OS won't be backwards compatible though. They would have to produce managed versions of Office, IE, etc first. They will have to produce a virtual machine to run unmanaged apps.

The pain would be something similar to the move from Mac OS9 to OSX.

Answer 4

COM was the last major technology that MS actually dogfooded. MS are continuing to build new APIs that depend on COM; for example, Vista's new Media Foundation (a kind of successor to DirectShow, which was also COM-based) is a COM API. So is Direct3D10 (and I would assume D3D11). I don't think it's going to disappear any time soon, and for a lot of Windows programming tasks it's not at all redundant.

Answer 5

I suppose that depends on what you mean by 'raw'. I still find the need to expose COM APIs from .Net class libraries on occasion. Makes the process of migrating from certain platforms to .Net a lot easier since I can replace small pieces via COM.