Title: The .NET and .COM Interoperability Handbook
Author: Alan Gordon
Publisher: Prentice Hall, 2002, ISBN 0-13-046-130X
Pages: 678
Price: $44.99
On the front of The .NET and COM Interoperability Handbook, by Alan Gordon, are several bold claims, including the announcement that this book is "The most in-depth guide to .NET/COM interoperability every published!" Since this is the only book I've yet read on the subject, I can't dispute this claim, but I can say that this book covers a lot of material. It's a big book —around ~650 pages—but thankfully, it is well organized, and written in an easy and enjoyable style. One part of the appeal is the fact that the chapter breakdown is logical and results in a digestible format. The book is divided into 12 chapters, most of modest size.
Chapter 1, "What's in a name?" is a whistlestop tour of .NET, COM, COM+, and their various related technologies. It includes some amusing anecdotes about the early origins of C# and .NET. Chapter 1 also contains a (perhaps too) brief comparison of .NET and Java. This is where I had my first philosophy problem with the book, in the form of a statement that may well wrankle with distinguished C++ practitioners: "[C++ and Java] are simplified and more object-oriented variants of C." Few would agree with the first half of this statement; the second half reflects the typical Java (and now .NET) misunderstanding/misinterpretation of C++. C++ is not an object-oriented language at all; it is a language that supports object-oriented programming (along with a host of other programming paradigms), and can do so more completely than either Java or .NET. Gordon later highlights multiple-inheritance as a major feature of C++ that would be strongly missed by C++ developers, which again does not reflect a modern view of C++.
Chapter 2, "Comparing COM and .NET," does just that. Gordon introduces his concept of software bus, which is a nice analogy, and the rest of the chapter ably and succinctly covers the important issues of life-cycle management, programming-language independence, transparency, extensibility, and versioning. However, I had serious issues with some of the conceptual messages. Gordon asserts that "A garbage collecting environment is the best of all possible worlds for developers," which is a very bold statement. Another is "If you talk to software developers who know anything about [OOD/P] and you mention extensibility the first word out of their mouths will likely be inheritance"; again, I struggle to take this seriously.
Chapter 3, "Exploring the CLR," describes problems of language variations in support for types in COM, and then glosses over the same thing (the CLS) with .NET. The rest of the chapter is good, with discussions of assemblies (with useful and practical information), metadata, MSIL, garbage collection, and code access security. Chapter 4 provides a good overview of the C# language. Chapter 5, "Using Visual Studio .NET," had me very excited at first. But alas, it is not much more than a quick look at the GUI. When Gordon brought up the subject of signing, I was looking forward to his introducing a purpose-built VS.NET plug-in (maybe in C#, demonstrating interoperability) to handle signing within the IDDE; alas we were just shown the command-line SN.exe tool.
Chapter 6, "An introduction to COM Interop," is where the book really starts, and, it is well worth the journey. Chapter 6 explains clearly how .NET and COM interact, and ably describes the Runtime Callable Wrappers (RCWs) and COM Callable Wrappers (CCWs). It also discusses the garbage collection problem with RCWs, and the lackluster (my word) attempt at correct semantics that is the ReleaseComObject() method; strangely, though this problem of lost resources is well illustrated by the author's own example, he fails to offer sufficient warning about, or criticism of, this fundamental flaw in the .NET/COM interoperability architecture.
The chapter contains a good illustration of the costs and hassles of late binding. There's a nice discussion of accessing .NET from COM, though in my opinion the recommendation should be that the ClassInterface attribute of choice is None (exporting only implemented interfaces) rather than AutoDispatch (providing class methods via late-binding).
There's a real shocker in this chapter: Gordon discusses the problem with locating .NET assemblies when they're used in COM clients and advises users of, for example, VB 6 to put them in the VB6 application directory! This kind of thing would not be tolerated in a commercial environment and is absolutely not to be recommended. The answer to the problem (which is covered in the book) is to use the codebase attribute.
Chapter 7, "Advanced .NET to COM Interop," covers things in more detail. It is the largest (over a hundred pages), which is commensurate with this being the primary form in which engineers will integrate COM and .NET. There's a thorough explanation of events and delegates and their relationship to connection points, along with a useful explanation of apartments. The description of Primary Interop Assemblies is clear and informative. The same can be said of the remaining parts of the chapter, including advanced marshalling and ActiveX controls. However, the chapter merely explains the lost reference problem, and in no way points out this as a major flaw, given that it is not something that a programmer can rectify in any way. Also, performance (one of my favourite issues) could have been given a lot more flesh.
Later chapters cover topics such as advanced COM, .NET services, and .NET remoting. The discussion of .NET remoting was really interesting. It covered the basics of the remoting architecture and remoting types, presenting a straightforward illustrative example. The chapter also contains a great refresher on the intriguing, but always obscure, subject of monikers. A final chapter on migration is a bit brief, but it covers the subjects of vertical and horizontal migration well.
How does the book stand up overall? It's not the deepest treatment one can imagine, which leaves you wondering whether it does, as also claimed on the front, cover "every .NET/COM interop option, "gotcha," and workaround." What can be said is that it covers a lot of material, and I feel a lot more informed for the reading. (I'll blame the publisher for the marketing hyperbole.)
This informative book did exactly what I needed it to do, which was to arm me with the necessary introductory information on using COM from .NET. Chapters 3, 6, 7, and 8 are excellent; of the rest, only Chapter 5 could have been better left out. I like the writing style very much and would be interested in the author's previous work. Where I had problems was in some of the messages behind the work. Gordon confesses to having formerly been a big fan of COM (he once wrote a book on COM and COM+) but he says he has now seen the light. Coupling this with some odd comments on C++, and an almost total lack of criticism of .NET's failings, I am left with the impression that he sees the world of software engineering as a market that is served by only one solution, and that that solution is .NET. It's just not true, and probably never will be.
For me, a good technical book has to have one or two chapters that tell me something I may otherwise not have learned. This book satisfies that criterion, and it is also easy to read and entertaining. It doesn't have a bibliography, which is a shame. It scores well for being instructional, and though its critical score is low, it succeeds in its role as a handbook. If I hadn't had a copy to review, would I buy it? Certainly.