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

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.