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

问题描述

我有一个 COM dll ，它由使用 COM Inter-op 的 .NET 应用程序使用.在其中一个 CoClasses 中，有一个名为 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 客户端，他们继续引用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 内置的类型库生成器中的黑客攻击的副作用.它有一个解决由不区分大小写的语言引起的问题的方法.这可能会在一个外壳中声明一个类型，但在另一个外壳中的其他地方引用它.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 非常粗糙，它采用第一个 遇到的标识符的大小写，然后更改任何后续标识符的大小写以匹配.意外大小写更改的最典型原因是参数名称，通常拼写为小写首字母.因此，您可能在以前版本的代码中有一个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屋！