重命名COM类属性是否会破坏DLL的向后兼容性？

核心结论 #

该操作会破坏向后兼容性，所有调用过该属性的客户端都需要做适配，是否需要重新构建取决于客户端的调用方式。

COM的核心设计原则之一是公开接口一旦发布就不可修改，任何对接口成员名称、顺序、签名的改动都可能引发兼容问题，针对你的场景分情况说明如下： #

1. 已编译完成、不需要重新构建的客户端兼容性 #

• 使用自定义IUnknown派生接口、走vtable早期绑定的客户端（比如原生C++客户端）：
  如果你仅修改IDL/头文件中的属性名称，没有调整该属性对应的get_SomeProperty/put_SomeProperty方法在接口定义中的顺序，没有修改方法签名、接口IID，那么已编译好的客户端可以正常运行。因为这类客户端在编译阶段已经把属性调用解析为vtable的固定偏移地址，运行时不依赖属性名做查找。
• 使用IDispatch自动化接口、走晚期绑定的客户端（比如脚本调用、C# dynamic调用、VB6客户端）：
  100% 会出现运行时错误。这类客户端大多通过属性名称或者对应的DISPID查找成员，你修改属性名后，客户端调用SomeProperty时会直接返回DISP_E_MEMBERNOTFOUND错误，完全无法正常运行，哪怕你保留原来的DISPID也没用，因为客户端是按名称查找的。

2. 需要基于新版SDK重新编译的客户端兼容性 #

不管使用哪种绑定方式，只要客户端代码中曾经调用过SomeProperty，用你新版的头文件、TLB、互操作程序集编译时都会直接报「找不到成员」的错误，必须修改代码把SomeProperty替换为Reserved才能编译通过，所有用到该属性的客户端都必须修改代码重新构建。 #

更稳妥的处理方案 #

既然该属性已经废弃多年，调用时仅返回E_NOTIMPL，完全不需要做重命名操作，保留原名称留在接口中即可，几乎不会产生额外的维护成本，还能避免所有兼容风险。

内容的提问来源于stack exchange，提问作者Eugen Kizim