多年来,我一直是Juval Lowy在.NET开发方面的教学和指导的崇拜者.他还写了我最喜欢的书之一:Programming .NET Components.
然而,在最近的DotNet Rocks播客(2010年1月)讨论WCF/COM和.NET时,他发表了一些令我惊讶的评论:
JuvalLöwy: ..... 在.NET中,看,这里的每个类都是COM对象.我们知道.事实上,它远远超过COM,因为我们有git编译,我们有垃圾收集,我们有安全堆....
卡尔富兰克林:嗯,你应该澄清一下.我的意思是,每个对象都不是COM对象.每个对象都具有COM对象的功能,但.NET Framework不是COM库.
JuvalLöwy: 不,不.首先,.NET实际上是建立在COM之上的.这都是COM下面的.
然后,在卡尔富兰克林要求澄清这一评论之后:
卡尔富兰克林:是的,我明白了.我的问题是基于COM构建的.NET？
JuvalLöwy:当然,所有COM都在下面.
Carl Franklin:不,我知道它是交织在一起的,而且是必需的,但是当你新建一个.NET对象时,你并没有创建一个COM对象.
JuvalLöwy:你正在创建一个.NET对象,但我所说的只是.NET构建在底层.这都是C++和COM.
Carl Franklin:它是C++,但你没有通过COM接口注册COM对象.除非你专门做到这一点,否则不是全部.
JuvalLöwy:但有些东西在下面使用COM,但这不是重点.忘记它是如何制作的.
你怎么看这些评论？
虽然我理解(并且已经确认)某些系统程序集是用非托管C++编写的,但是它们是"所有COM下面"也是有效的吗？
我是在假设完全可以编写与COM/ATL/ActiveX完全无关的.NET CLI兼容的C++程序集？
以下是相关播客的PDF文字记录.见第7页.
Meh*_*ari 20
我认为他正在讨论CLR的底层实现.根据我的理解,他不是在讨论COM和.NET世界的交互.他只是告诉我们他们在运行时的实现中使用了C++和COM.
我是在假设完全可以编写与COM/ATL/ActiveX完全无关的.NET CLI兼容的C++程序集？
是的,您可以使用C++/CLI创建与COM无关的纯MSIL程序集.
Ash*_*Ash 17
Dave Markle的回答让我想起了Jeff Richter在CLR Via C#中所说的话.
(第21章,CLR托管和AppDomains)
.NET Framework在Microsoft Windows之上运行.这意味着必须使用Windows可以与之交互的技术构建.NET Framework.对于初学者,所有托管模块和程序集文件必须使用Windows可移植可执行(PE)文件格式,并且可以是Windows EXE文件或动态链接库(DLL).
在开发CLR时,Microsoft将其实现为DLL中包含的COM服务器; 也就是说,Microsoft为CLR定义了标准COM接口,并为此接口和COM服务器分配了GUID.安装.NET Framework时,表示CLR的COM服务器在Windows注册表中注册,就像任何其他COM服务器一样.如果需要有关此主题的更多信息,请参阅.NET Framework SDK附带的MSCorEE.h C++头文件.此头文件定义GUID和非托管ICLRRuntimeHost接口定义.
我猜这与解释Juval的评论非常接近.
Alex DeLarge在另一个答案中也提出了一个很好的观点,即CLR本身的实现与基类库程序集之间存在差异.
我当然专注于BCL程序集(Juval:"这里的每个clss都是一个COM对象")和应用程序集,所以这可能是混乱的原因.
Bri*_*sen 16
我相信Löwy特别谈论.NET的Windows实现.由于COM是Windows基础结构的重要组成部分,因此.NET使用它并不奇怪.但是,.NET也可以在非Windows平台上使用,所以我不知道COM是如何成为.NET 的基础.
这几乎就像Löwy故意试图不清楚他说的那样.我没有听过播客,但从变音符号判断,我认为英语不是他的第一语言.
您在.NET中使用的某些对象实际上是COM对象的包装器.你创建的.NET对象会做很多COM应该做的事情,而且没有COM令人讨厌的烦恼.我不认为"它是所有COM在下面"的陈述是准确或清楚的.
我希望这次采访是与杰夫里希特进行的.;-)