Visual Studio 扩展接口中未使用的方法
在 Visual Studio 包的 IVsHierarchy 界面中，有方法 Unused0、Unused1、Unused2、Unused3 和Unused4 具有以下描述：
Adds new methods without recompiling or breaking binary compatibility.
有人可以更详细地解释一下吗？这些方法究竟有何帮助？
In IVsHierarchy interface for Visual Studio packages, there are methods 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 exactly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Visual Studio 扩展对象是在 COM 中实现的。 COM 中的一项硬性规则是接口是不可变的。更改接口需要重新分配接口 IID。标识接口的 guid。这会给使用该界面的任何人带来很多痛苦。他们必须更改代码并重新编译。
这种不变性要求的存在是因为 COM 接口在底层是作为方法地址表实现的。当客户端代码假设的表与服务器实现的实际表不匹配时，就会发生灾难。或者换句话说，当接口不二进制兼容时。这会产生非常难以诊断的运行时错误，当客户端代码最终调用错误的方法或使用根本没有关联方法的表槽时会触发该错误。这就是臭名昭著的 COM DLL Hell 问题。更改 IID 可以解决这个问题，客户端代码将无法再找到旧的实现。仍然是一个令人讨厌的错误，但至少很容易诊断。
占位符允许 Microsoft 向界面添加新方法，但不会破坏表格布局。因此不必重命名接口并重新分配接口 IID。因此不会强迫插件供应商重新编译他们的插件。除非新的插件尝试使用旧的接口实现，否则仍然无法工作。但有可能出现一个不错的异常消息而不是令人讨厌的 AccessViolation。
The Visual Studio extension objects are implemented in COM. One hard rule in COM is that interfaces are immutable. Changing an interface requires re-assigning the interface IID. A guid that identifies the interface. That causes lots of pain to anybody that uses the interface. They'll have to alter their code and recompile it.
This immutability requirement exists because under the hood COM interfaces are implemented as a table of method addresses. Disaster strikes when there's a mismatch between what the client code assumes the table looks like and the actual table as implemented by the server. Or in other words, when the interfaces are not binary compatible. That produces very hard to diagnose runtime errors, triggered when the client code ends up calling the wrong method or uses a table slot that doesn't have an associated method at all. This is the infamous COM DLL Hell problem. Changing the IID solves it, the client code simply won't be able to find the old implementation anymore. Still a nasty error but at least easy to diagnose.
The place holders are there to allow Microsoft to add new methods to the interface but not break the table layout. And thus won't have to rename the interface and reassign the interface IID. And thus won't force addin vendors to recompile their addins. Unless a new addin tries to use the old interface implementation, that still won't work. But with odds for a decent exception message instead of a nasty AccessViolation.