Chapter 1: COM and .NET

.NET is the new wave of software development, introducing new technologies and languages. Whats happening to the previous wave of technologies, in particular COM? This chapter discusses the place of COM in the new .NET world and presents an overview of the major topics and issues that COM programmers face in the brave new world of .NET. Many of these topics and issues will be covered in more depth in later chapters.

Is COM Dead?

The short answer is No, not in the foreseeable future.

COM underlies the architecture of the current generation of Windows operating systems, and as such, it is deeply embedded in the operation of just about every facet of Windows programming. Access to many pieces of system functionality, from shell programming through database access to graphics programming using DirectX, is provided by COM interfaces. There are hundreds, if not thousands, of COM components and ActiveX controls in use throughout the world. This situation isnt going to change overnight, so programmers will still need to work with COM.

As if in confirmation of this, Microsoft has provided a new, much simpler way to create COM components using attributed programming, as youll see in Chapter 6. The fact that Microsoft developers have put a lot of effort into providing a new way to work with COM code shows that COM programming is still regarded by Microsoft as something that needs support in its new generation of programming tools.

But the history of Windows programming is full of examples of technologies evolving to support simpler ways of performing common tasks . Consider Visual Basic: once everyone had to write Windows programs in C, using the Windows SDK. Such coding required a considerable amount of arcane knowledge, and it was not trivial to write even a simple program. Visual Basic came along and made it possible to produce many types of Windows applications with very little effort, hiding the Windows infrastructure behind a programmer- friendly front end. There were still many obscure or clever programming techniques that forced you to use C, but a large proportion of everyday applications could be produced much more quickly in Visual Basic than in C.

Were seeing the same process at work with .NET and COM. While COM has been successful as a component model, aspects of the development process could be improved. Areas such as manual object lifetime management and cross-language data communication require considerable skill, and in general COM imposes a considerable learning curve on the programmer. The infrastructure required to permit the development of distributed component applications has become complex and hard to master. In addition, the fact that every machine in a distributed COM application needs to understand the DCOM protocol places limits on interoperability, and the lack of security associated with ActiveX controls running in browsers has limited the development of browser- based user interfaces (UIs).

.NET has preserved the many advantages of the COM model, while resolving many of the problems. Ill mention three specific areas here; others will emerge in later chapters.

First, XML Web services provide a way for parts of distributed applications to talk. SOAP (Simple Object Access Protocol) uses XML over HTTP to make method requests to a server. This arrangement has several advantages: HTTP is far more firewall-friendly than the DCOM binary protocol, and the use of XML and HTTP provides compatibility with a wide range of systems.

XML Web services are very useful when parts of applications on different machines are talking across the Internet or intranets , but how useful are they for cross-process communication? .NET Remoting replaces DCOM and can be used for secure, efficient, extendable communication using any .NET language. Unlike DCOM, it supports different transport mechanisms out of the box (HTTP and TCP are currently supported), different encodings (SOAP and binary are standard) and different types of security (Secure Sockets Layer [SSL] and Internet Information Services [IIS] security are standard). And because .NET Remoting is implemented by means of classes and interfaces, you can extend the mechanisms.

Finally, you can now use Windows Forms controls on Web pages. These controls, used mainly with desktop applications, provide the same packaged rich functionality as ActiveX controls, but they are subject to the same versioning and security checking that is applied to all .NET code. This means that using such controls in Web pages will remove the security concerns that currently apply to ActiveX controls.

Future releases of Windows will integrate the .NET common language runtime into the operating system, and system services will be accessible through .NET mechanisms. At that time, most people will be able to do most of what they need to do using .NET mechanisms, and the importance of COM will start to decline for most programmers.

In the future, COM programming will tend to be the preserve of the C++ programmer. To a large extent, C++ programmers have always been the ones doing heavy-duty COM coding, but in the future Visual Basic .NET and Visual C# programmers will find they can do just about all they want and need to do without using COM or ActiveX. However, some COM programming tools, such as the Active Template Library (ATL), remain accessible only through C++. In particular, Ill mention ATL Server, which provides a mechanism for writing compact and efficient ISAPI server extensions in C++. And in the same way that it is still necessary to drop from C or C++ into assembler for performance reasons, sometimes a COM component written in C++ can be far more efficient than a .NET component.