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.

Collar

What a silly argument. He might as well have said "it is all assembly underneath". It doesn't matter what tools they used to implement .NET. Of course some of it is using COM underneath, just like some of it is using Win32 calls underneath, and some of it is written in C++. That is utterly and completely irrelevant. – Toback

@jalf, yes I thought it was not helpful to the overall discussion when Juval started down this path. – Collar

Answer 1

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. ;-)

Wiburg

"Unclear" or "nuclear"? I think he was being intentionally provocative, also going on to say that all .NET objects should be WCF services. English is definitely not his first language. Between his accent and road noise, I found it hard to listen to in my car. BTW, they have done Jeff Richter interviews also. – Embraceor

@Dave, you have read my mind :) I own a copy of the excellent CLR Via C# and can't remember Jeff Richter saying anything like this. – Collar

Answer 2

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.

Take

So the real inaccuracy in Juval's comments is saying "it's all COM underneath". Should be something like "COM is a key part of the .NET runtime" – Collar

@Ash: Indeed. You can build a CLI compatible runtime without touching COM. Definitely .NET objects are not necessarily COM objects. – Take

I left out a very important quote that caused the most confusion. Juval actually says " in .NET, lo and behold, every class here is a COM object". I've now added it. – Collar

@Ash: "every class" is ambiguous. Is he talking about managed classes? If so, I doubt it. If he's talking about the classes used in coding the CLR, then that's understandable but that has nothing to do with the managed world. It's an implementation detail. The CLI spec absolutely does not require the runtime to be implemented on top of COM. – Take

the podcast context makes me think that he is talking about managed classes written by application developers. Juval is undoubtedly a smart guy, but in my opinion he sometimes make comments that seem to be specifically designed to grab attention by appearing controversial or even factually wrong. Then when called on these comments, he then points out a subtlety (or edge case) that shows that he is technically correct. I think this is a classic example. I even detected a bit of back pedaling when Carl Franklin asked him to clarify his comments. – Collar

Answer 3

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.

Collar

This is interesting. One can see that the original comments must be understood with a "grain of salt". But, all microsoft technologies are built on top of every other one. It's sort of a layer cake. Or a garbage dump. ;-) – Sordino

Answer 4

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.

Humpage

Good point regarding Mono. I guess you could say any application running on Windows is "all COM underneath". However this is really just implying that COM is still a key part of the Windows OS itself. – Collar

I left out a very important quote that caused the whole confusion. Juval actually says " in .NET, lo and behold, every class here is a COM object". I've now added it. – Collar

@Ash: Even that is not true. A process is not a COM process until at least one thread has loaded OLE32.DLL and called CoInitialize(). – Pleinair

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.

Starstarboard

What registry dependencies does .NET not have? You have registration of .NET packages in the registry just like DCOM/COM components have to be registered, don't you? – Sordino

@Warren P : actually, COM components don't necessarily require registration. – Pleinair

@Warren P: A COM component should be put in HKEY_CLASSES_ROOT to be used (I know there are exceptions, Isolated COM etc). To use a .NET class you don't have to put anything about that class in the registry. – Starstarboard

Answer 6

I think from this and in presence of ICLRRuntimeHost and various other unmanaged interfaces to CLR internals it's pretty much obvious that .NET is actually built on top of COM.

Canescent

But isn't interfacing to COM (and hosting the CLR) very different from the CLR itself being implemented using COM? – Collar

Answer 7

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

Vasti

I left out a very important quote that caused the whole confusion. Juval actually says " in .NET, lo and behold, every class here is a COM object". I've now added it. – Collar