COM接口和二进制兼容性 [英] COM Interfaces and Binary Compatibility

问题描述

在白天工作，我工作在VB6（我知道，但不要模仿的痛苦...）应用程序，使用我们编写的许多库（也在永远卓着的VB6）。其中一个支持库有通过公共属性暴露的私有成员的负载，我被要求删除属性，并将私有成员变量提升为与原始属性同名的公共字段。

In the day job, I work on a VB6 (I know, but don't mock the afflicted...) application that uses a number of libraries we have written (also in the ever illustrious VB6). One of these supporting libraries had a load of private members exposed via public properties, and I was asked to remove the properties, and promote the private member variables into public fields with the same name as the original properties.

现在，我不是COM专家，但我的印象是一个类中的每个暴露的项目都有它自己的GUID。因为我们将从一个情况，其中每个值从2 Guids（Property Get和Property Let）到他们只使用一个（公共领域），我期望这会打破二进制兼容性 - 但它似乎它hasn

Now, I'm no COM expert, but I was under the impression that each and every exposed item on a class gets it's own GUID. Since we would be going from a situation where each value went from 2 Guids (Property Get and Property Let) to one where they only used the one (the public field), I was expecting this to break binary compatibility - but it seems it hasn't done that.

任何人都可以解释为什么？

Can anyone explain why?

推荐答案

我认为这有点比这更微妙。您将获得COM接口的GUID（而不是每个单独的字段/方法）。根据我的理解，二进制兼容性试图解决如果您当前编译的接口向后兼容您的DLL的参考版本（假设您有一个），只有更改GUID，如果它们不兼容。

I think it's a bit more subtle than that. You get a GUID for the COM interface (not each individual field/method). As I understand it the binary compatibility attempts to work out if the interface your currently compiling is backwards compatible with a reference version of your DLL (assuming you have one) and only changes the GUID if they are not compatible.

因此，我也感到惊讶，它已经决定删除​​所有的get / set方法是兼容的：/

I'm therefore also surprised that it has decided removing all the get/set methods is compatible :/

这篇关于COM接口和二进制兼容性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！