Programming .NET Components, 2nd Edition

Binary Compatibility

As explained in Chapter 1, one of the core principles of component-oriented programming is binary compatibility between client and server. Binary compatibility enables binary components because it enforces both sides to abide by a binary contract (typically, an interface). As long as newer versions of the server abide by the original contract between the two, the client isn’t affected by changes made to the server. COM was the first component technology to offer true binary compatibility free of DLL Hell (described in the previous chapter), and many developers have come to equate COM’s implementation of binary compatibility (and the resulting restrictions, such as immutable COM interfaces) with the principle itself. The .NET approach to binary compatibility is different from that of COM, though, and so are the implications of the programming model. To understand these implications and why they differ from COM’s, this section first briefly describes COM’s binary-compatibility implementation and then discusses .NET’s way of supporting binary compatibility.

COM Binary Compatibility

COM provides binary compatibility by using interface pointers and virtual tables. In COM, the client interacts with the object indirectly via an interface pointer. The interface pointer actually points to another pointer called the virtual table pointer. The virtual table pointer points to a table of function pointers. Each slot in the table points to the location where the corresponding ...