.NET终结了COM?

原创 2002年03月27日 14:03:00

Is .NET the end of COM?<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

By David Chappell

 

 

With the exception of Windows NT, COM is the most important developer technology introduced by Microsoft in the past decade. COM has become ubiquitous, and it is applied today in a large majority of software written for Windows systems.

 

Microsoft now tells us that .NET is the next big thing. The .NET initiative includes a number of technologies, but the most important of these looks to be the .NET Framework. Including a new approach to components based on a Common Language Runtime (CLR), a unified class library and a next-generation Web development environment called ASP+, the .NET Framework will eventually have an impact on every Windows developer. Microsoft is placing an enormous bet here, and .NET really does look like the next big thing in the Windows world.

 

But what does this mean for COM? While the component technology in the CLR grew out of COM, it isn't COM as we know it today. The CLR does not just hide IUnknown and all the rest of COM's mechanics, it completely dispenses with them. Building native applications using the .NET Framework doesn't rely at all on conventional COM technology.

 

So COM must be dead then, right? Not exactly—the truth is a bit more complicated.

 

First, one wholly valid way to think about COM is as a programming model for creating components. To a Visual Basic programmer, this is exactly how COM looks. IUnknown and other COM details have always been hidden from Visual Basic people (who are the largest group of COM developers by far). For this audience, the switch to the CLR-based components in the .NET world should not be traumatic. Viewed as a programming model rather than as a detailed implementation, components in the .NET Framework are literally an ev-olution of COM rather than a replacement for it.

 

Second, Microsoft realizes that lots of COM code exists in the world. Accordingly, interoperability between components built using the .NET Framework and COM is built into the CLR. A .NET Framework component can look like a COM object to COM clients, while a COM object can look like a .NET Framework component to a client built using the CLR. Neither of these things requires any significant work for developers, and I expect interoperation to be both easy and common.

 

Third, even applications de-veloped using the .NET Framework will exploit some parts of COM. In particular, the CLR does not attempt to replicate any of the functionality of COM+. .NET Framework applications that need transactions, object pooling and other COM+ services will be deployed wrapped in COM components. Understanding how COM+ works will still be important in a .NET world.

 

Finally, purely COM-based development is not dead. The .NET Framework is not scheduled to ship for some time yet, and so Windows development will continue in its current COM-oriented vein for quite a while. And even after the .NET Framework is available, some projects will likely still use COM rather than .NET. The execution model imposed by the CLR represents real progress for many kinds of applications, but it is not the right answer for everything. Some software, especially system-level code, will still be developed using COM.

 

So does the arrival of .NET mean the end of COM? In some ways, the answer is yes. Building brand-new apps from scratch using the .NET Framework won't require any knowledge of today's COM technology. That technology simply isn't present in the .NET Framework. (Find me the developers, though, who will cry big tears at the thought of never having to deal with COM's details again.)

 

In other important ways, however, COM will go on. As a programming model, as a way to interoperate with existing code, as a technology for transactions and other services, and even as an explicit development foundation, it will definitely get used. COM is not dead.


David Chappell is principal at Chappell & Associates, an education and consulting firm focused on enterprise software technologies. He can be reached via E-mail at david@davidchappell.com.

C#开发COM组件

原文:http://blog.csdn.net/soudog/article/details/1593346 1.    概述        Microsoft在解决和以往的COM和SDK开发...
  • jiftlixu
  • jiftlixu
  • 2016年03月09日 14:20
  • 3100

从OLE到COM,再到ActiveX,再到.NET

微软从OLE到COM,再到ActiveX,再到.NET的发展历史的简介
  • just0kk
  • just0kk
  • 2016年03月02日 21:31
  • 767

COM组件与.Net组件的比较

1、COM组件与.Net组件的比较        COM技术要早于.Net技术。COM定义了一个组件模型,在该模型中,组件可以使用不同的编程语言进行编写,其可以在本地进程中使用,也可以跨进程使用或...
  • Chinamming
  • Chinamming
  • 2013年11月21日 13:47
  • 3479

C#开发COM组件供其他开发环境或工具调用介绍

由于工作原因涉及到这一块的开发,由于之前并未接触过,所以本篇文章也是在参考了各种资料后,自己实现并通过通过测试之后所整理的备忘录以及一些个人观点。 希望对刚接触这类型开发的朋友有所帮助,若有不足...
  • xiunai78
  • xiunai78
  • 2013年09月10日 11:23
  • 6200

.Net之路(十四)com组件、OLEDB导入EXCEL

.NET com组件
  • chenfanglincfl
  • chenfanglincfl
  • 2014年06月13日 23:55
  • 1992

PB 调用.NET COM组件

今天需要作一下pb引用.net的外接程序类。反复测试都没有成功。看到这篇文章解决了我的问题。在此感谢。综合我的碰壁经验。需要注意以下两点。 1..net项目需要勾选生成 com组件。 2....
  • pengdayong77
  • pengdayong77
  • 2015年06月30日 12:29
  • 660

组件与.NET互操作

1、何谓组件技术? 组件技术就是利用某种编程手段,将一些人们所关心的,但又不便于让最终用户去直接操作的细节进行了封装,同时对各种业务逻辑规则进行了实现,用于处理用户的内部操作细节,甚至于将安全机制和事...
  • bigpudding24
  • bigpudding24
  • 2015年10月26日 13:10
  • 589

linqToXml终结了,封装成了操作类。。。

闲来无事写了一个xmlHelper类。感觉比市面上流行的那个好用一些。 好处:使用反射,所以传入参数,查询条件等等全是string类型。 坏处:使用反射和表达式树,应该效率会差一点点。...
  • yzh900927
  • yzh900927
  • 2015年01月07日 11:11
  • 268

.NET框架与COM

.NET框架与COM 可复用软件不是一个新概念。八年来,人们一直在使用各种形式的组件对象模型(COM)。事实证明,它是最为成功的可复用软件模型。COM引进了“组件”的概念——它是可复用的代码块,可以...
  • u014739778
  • u014739778
  • 2014年04月30日 08:05
  • 245

.Net调用Office Com组件的原理及问题检索com类工厂组件检索 COM 类工厂中 CLSID 为 {XXX} 的组件失败

.net调用office组件进行Excel、Word、ppt的一些操作,需要做一下操作: 1、正确全面的安装office 2、DCOM配置权限(64位系统要添加32位组件【mmc -32】...
  • DonetRen
  • DonetRen
  • 2017年12月09日 09:58
  • 172
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:.NET终结了COM?
举报原因:
原因补充:

(最多只允许输入30个字)