Is .NET the end of COM?
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.
