Unused Methods in the Visual Studio Extension Interface

In the IVsHierarchy interface for Visual Studio packages, there are Unused0 , Unused1 , Unused2 , Unused3 and Unused4 with the following description:

 Adds new methods without recompiling or breaking binary compatibility. 

Can someone explain this in more detail. How do these methods help for sure?

+4
source share
1 answer

Visual Studio extension objects are implemented in COM. One tough rule in COM is that interfaces are immutable. Changing the interface requires reinstalling the IID interface. A pointer that identifies an interface. It hurts a lot to anyone who uses the interface. They will have to change their code and recompile it.

This requirement of immutability exists, since under the hood COM interfaces are implemented as a table of method addresses. An accident hits when there is a mismatch between what the client code assumes the table looks like and the actual table is implemented by the server. Or, in other words, when the interfaces are not compatible with binary files. This makes it very difficult to diagnose runtime errors caused when client code finishes calling the wrong method or uses a table slot that does not have a method associated with it. This is the notorious COM DLL Hell problem. Changing the IID solves it; client code simply cannot find the old implementation. Still an unpleasant mistake, but at least easy to diagnose.

Place holders are there to allow Microsoft to add new methods to the interface, but not break table layouts. And therefore, there will be no need to rename the interface and reassign the IID interface. And, thus, they will not force sellers of additional modules to recompile their add-ons. If the new addon does not try to use the old interface implementation, this still will not work. But with the chances of a decent exception message instead of the unpleasant AccessViolation.

+6
source

Source: https://habr.com/ru/post/1395007/


All Articles