Is .NET “all COM underneath”?

Question

I've been an admirer of Juval Lowy's teaching and guidance in .NET development for a number of years. He's also written one of my favorite books: Programming .NET Components.

However on a recent DotNet Rocks podcast (Jan 2010) in discussing WCF/COM and .NET, he made some comments that greatly surprised me:

Juval Löwy: ..... in .NET, lo and behold, every class here is a COM object. We know that. In fact, it's much more than COM because we've got the git compiling, we've got garbage collection, we've got the Security Stack....

Carl Franklin: Well, you should clarify that though. I mean, every object is not a COM object. Every object has the capabilities that a COM object does, but the .NET Framework isn't a COM library.

Juval Löwy: No, no. First of all .NET is actually built on top of COM. It's all COM underneath.

Then, after Carl Franklin asks for clarification on this comment:

Carl Franklin: Yeah, I get that. My question was is .NET built on COM?

Juval Löwy: Of course, it all COM underneath.

Carl Franklin: No. I know it's intertwined and it's required, but when you new up a .NET object you're not creating a COM object.

Juval Löwy: You're creating a .NET object, but all I'm saying is that .NET is built underneath. It's all C++ and COM.

Carl Franklin: It is C++ but you're not registering a COM object through the COM interface. It isn't all that stuff unless you specifically do that.

Juval Löwy: But some of the stuff is using COM underneath, but that's beside the point. Forget about how it's made.

How do you read these comments?

While I understand (and have confirmed) that some of the System assemblies are written in unmanaged C++, is it also valid to say that they are "all COM underneath"?

I was under the assumption it is perfectly possible to write .NET CLI compliant C++ assemblies that have absolutely nothing to do with COM / ATL / ActiveX?

Here is the PDF transcript for the podcast in question. See Page 7.

Answer 1

I think he's talking about the underlying implementation of the CLR. From my understanding, he's not talking about the interaction of the COM and .NET worlds. He's merely telling us that they have used C++ and COM in the implementation of the runtime.

I was under the assumption it is perfectly possible to write .NET CLI compliant C++ assemblies that have absolutely nothing to do with COM / ATL / ActiveX?

Yes, you can use C++/CLI to create purely MSIL assemblies that have nothing to do with COM.

Answer 2

I believe Löwy is specifically talking about the Windows implementation of .NET. Since COM is such a huge part of the infrastructure of Windows it isn't odd that .NET uses this. However, .NET is available on non-Windows platforms as well so I don't see how COM is the foundation for .NET.

Answer 3

It's almost as if Löwy is intentionally attempting to be unclear in what he says. I've not listened to the podcast, but judging by the umlauts, I reckon English is not his first language.

Some objects that you use in .NET really are wrappers for COM objects. And a .NET object you create does a lot of what COM is supposed to do and more, without COM's nasty annoyances. I don't think the statement "it's all COM underneath" is accurate or clear.

I wish the interview had been with Jeff Richter. ;-)

Answer 4

I listened to that and my impression was that, while not 100% clear, he was talking more about the .NET runtime than the BCL.

Answer 5

.NET/CLR started life to be a better COM (Chapter 1 in this book)

But is is not based on COM as it has removed lots of the problem areas of COM. (Reference counting based memory managment, the unsafe pointers, registry dependencies..)

But it can use COM objects and it can wrap .NET objects in COM-wrapping. But a .NET object is not a COM object.

The hosting interface for the .NET implementation on Windows is based on a few COM interfaces.

Answer 6

Dave Markle's answer reminded me of something Jeff Richter said in CLR Via C#.

(Chapter 21, CLR Hosting and AppDomains)

The .NET Framework runs on top of Microsoft Windows. This means that the .NET Framework must be built using technologies that Windows can interface with. For starters, all managed module and assembly files must use the Windows portable executable (PE) file format and be either a Windows EXE file or a dynamic-link library (DLL).

When developing the CLR, Microsoft implemented it as a COM server contained inside a DLL; that is, Microsoft defined a standard COM interface for the CLR and assigned GUIDs to this interface and the COM server. When you install the .NET Framework, the COM server representing the CLR is registered in the Windows registry just as any other COM server. If you want more information about this topic, refer to the MSCorEE.h C++ header file that ships with the .NET Framework SDK. This header file defines the GUIDs and the unmanaged ICLRRuntimeHost interface definition.

I am guessing that this is pretty close to explaining Juval's comments.

Alex DeLarge also makes a good point in another answer that there is a difference between the implementation of the CLR itself and the Base Class Library assemblies.

I was certainly focusing on the BCL assemblies (Juval: "every clss here is a COM object") and application assemblies so this may be the cause of the confusion.