MIDL更改接口名称 [英] MIDL changes the Interface name

问题描述

我有一个COM dll，使用COM Inter-op的.NET应用程序会使用它. 在其中一个CoClass中，有一个名为IT6TrackData的接口，它有一个名为TrackData的get属性

I have a COM dll , which is consumed by .NET applications using COM Inter-op. In one of the CoClasses , there is an Interface called IT6TrackData and it has one get property called TrackData

从IDL文件中

Interface IT6TrackData
{
   [propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
}

在查看上述IDL文件的TLB文件时，该属性显示为trackData(小写的t) 出于某种原因，客户端应用程序将此属性称为trackData，并且到目前为止一切正常.

When the TLB file is viewed for the above IDL file, it shows the property as trackData ( t in lower case) For some reason the Client application were referring to this property as trackData and everything was working fine until now.

作为增强功能的一部分，上述接口已升级为具有put属性

As part of enhancement the above Interface was upgraded to have a put property

Interface IT6TrackData
{
   [propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
   [propput, id(1)] HRESULT TrackData([in]SAFEARRAY(BYTE) pVal);
}

现在，当查看上面的IDL文件的TLB文件时，它将显示为TrackData属性(t为大写)，这打破了旧的.NET客户端，这些客户端继续引用该.NET客户端. trackData中的小写字母"t".

Now when the TLB file is viewed for the above IDL File, it show the property as TrackData ( t is in upper case), this is breaking the old .NET clients who continue to refer to the trackData with the "t" in lower case.

我已经阅读了这篇知识库文章 http://support2.microsoft.com/kb/220137/en-gb

I have gone through this KB article http://support2.microsoft.com/kb/220137/en-gb

但是有没有解决的办法，有人知道这个问题的解决方法吗.

but is there a way out, does anyone know of a fix for this issue.

感谢您的关注.

IDL文件

import "oaidl.idl";
import "ocidl.idl";

 [
   object,
   uuid(72867CE8-41B6-459E-A258-C7A162A26D5E),
   dual,
   nonextensible,
   helpstring("ITFST6TrackData Interface"),
   pointer_default(unique)
 ]
 interface ITFST6TrackData : IDispatch{
   [propget, id(1), helpstring("property TrackData")] HRESULT TrackData([out, retval]   SAFEARRAY(BYTE) *pVal);
   [propput, id(1), helpstring("property TrackData")] HRESULT TrackData([in]SAFEARRAY(BYTE) pVal);
};
[
   uuid(1D7ABC17-2738-4373-9B6B-239E344DBD21),
   version(1.0),
   helpstring("SampleCom 1.0 Type Library")
]
library SampleComLib
{
   importlib("stdole2.tlb");
   [
       uuid(2013CC98-47A7-468F-912A-2A2CAE25E327),
       helpstring("TFST6TrackData Class")
   ]
   coclass TFST6TrackData
   {
        [default] interface ITFST6TrackData;
   };
};

推荐答案

这是Windows内置的类型库生成器中的hack的副作用.它有一种变通方法，可解决由不区分大小写的语言引起的麻烦.可以在一个框内声明一个类型，但在另一个框内其他地方引用它. Visual Basic是这种语言的主要示例.

This is the side-effect of a hack in the type library generator built into Windows. It has a workaround for trouble caused by a case-insensitive language. Which might declare a type in one casing but refer to it elsewhere in another casing. Visual Basic is the prime example of such a language.

hack非常粗糙，它采用遇到的 first 标识符的大小写，然后更改任何后续标识符的大小写以进行匹配.意外更改大小写的最典型原因是参数名称，通常以小写的首字母拼写.因此，在以前的代码版本中，您可能有一个"trackData"方法参数.

The hack is very crude, it takes the casing of the first identifier it encounters and then changes the casing of any subsequent identifier to match. The most typical cause of an unexpected casing change is the name of a parameter, typically spelled with a lower-case first letter. So you probably had a "trackData" method parameter in a previous version of the code.

在您的修订版中，标识符的顺序已更改，或者您已重命名或删除了该参数.现在改为获取"TrackData".

And in your revision, either the order of the identifiers changed or you renamed or removed that parameter. Now getting "TrackData" instead.

如果周围有现有的客户代码(取决于原始大小写)，那么您无能为力，只能在源代码中更改大小写.麻烦修复，但对您的客户来说并不奇怪，因为他们无法说出区别:)

If you have existing client code around that depends on the original casing then there's little you can do but change the casing in your source. Fugly fix, but unsurprising to your clients since they can't tell the difference :)

这篇关于MIDL更改接口名称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！