У меня есть COM dll, который используется приложениями .NET, использующими COM Inter-op.
В одном из CoClasses есть интерфейс, называемый IT6TrackData, и у него есть одно свойство get, называемое TrackData.
Из файла IDL:
Interface IT6TrackData
{
[propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
}
Когда файл TLB просматривается для вышеуказанного файла IDL, он показывает свойство как trackData (t в нижнем регистре)
По какой-то причине клиентское приложение ссылалось на это свойство как trackData, и до сих пор все работало нормально.
В рамках усовершенствования вышеупомянутый интерфейс был обновлен, чтобы иметь свойство put
Interface IT6TrackData
{
[propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
[propput, id(1)] HRESULT TrackData([in]SAFEARRAY(BYTE) pVal);
}
Теперь, когда TLB-файл просматривается для указанного выше IDL-файла, он показывает свойство как TrackData (t в верхнем регистре), это ломает старых клиентов .NET, которые продолжают ссылаться на
trackData с буквой «t» в нижнем регистре.
Я прошел эту статью KB
http://support2.microsoft.com/kb/220137/en-gb
но есть ли выход, кто-нибудь знает решение этой проблемы.
Ваше внимание ценится.
Файл 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 является ярким примером такого языка.
Взлом очень сырой, он принимает оболочку первый идентификатор, с которым он сталкивается, а затем изменяет регистр любого последующего идентификатора для соответствия. Наиболее типичная причина неожиданного изменения регистра — это имя параметра, обычно пишется со строчной первой буквой. Таким образом, у вас, вероятно, был параметр метода «trackData» в предыдущей версии кода.
И в вашей ревизии либо изменился порядок идентификаторов, либо вы переименовали или удалили этот параметр. Теперь вместо этого получаем «TrackData».
Если у вас есть существующий клиентский код, который зависит от исходного кожуха, то мало что можно сделать, кроме как изменить кожух в исходном коде. Чёткое исправление, но неудивительно для ваших клиентов, так как они не могут отличить 🙂