在2台机器上生成的.tlh是不同的

Sam*_*der 6 .net compiler-construction com interop typelib

我有一个.NET DLL,它有一些暴露给com的接口\类.在构建过程中生成一个.tlb文件,这个tlb由一些c ++代码引用.结果,编译器为tlb生成.tlh文件.

当我在本地运行构建时,其中一个接口中的一个属性最终会得到tlh中不具有相同名称的相应方法..net代码中的属性称为PropertyA,最终称为get_propertyA,而PropertyB最终称为get_PropertyB.当发生这种情况时我没有眨眼睛,只是使用了tlh中定义的方法,并假设一切都是笨拙的,但是当我编写这些更改时,构建对其他任何人都不起作用,因为编译器生成了名为get_PropertyA的属性, get_PropertyB(在propertyA中注意案例不匹配).

在两台机器上生成的tlb文件是相同的(根据十六进制比较器),并且tlh文件都由相同的编译器版本生成.

构建过程通过执行以下操作创建tlb:regasm path\to\dll\Mydll.dll -tlb:path\to\output\mydll.tlb

任何想法为什么我的本地版本最终与一个名称不正确的属性?或者我能做些什么来解决它?

更新:我读到tlbexp将使用它找到的字符串的第一个版本,并且可以通过重新编译来更改.虽然我没有使用tlbexp,但我想知道这是不是问题.我找到了与我的方法同名的参数(在其他方法中),但在开头有一个小写字母.所以我替换了所有这些.重建,没有变化.所以我然后重命名了我的COM方法.重建并获得预期的丢失方法错误.将方法重命名为原始名称,嘿,它似乎是固定的.因为它现在似乎工作,我不能让它再次失败我不能尝试建议的解决方案,但我喜欢重命名的想法,以防将来发生这种情况.

Ed *_*kes 5

我有同样的问题。

通过另一个SO问题(/sf/ask/49610501/),我发现了以下社区内容:

http://social.msdn.microsoft.com/Forums/zh-CN/clr/thread/5003c486-ed3f-4ec8-8398-a1251b0f9e74

引用该内容:

在tlbexp的文档中,有一项有用的社区内容:

http://msdn2.microsoft.com/en-gb/library/hfzzah2c(VS.80).aspx

引用:

“ / names选项的原因是类型库将每个标识符存储在一个不区分大小写的表中。遇到的第一种情况胜出。因此,如果有一个带有名称的参数,则名为Monitor的类可能最终会公开为“ monitor”。 / names可以保证大小写稳定。”(并且遇到标识符的顺序可以通过重新编译程序集而改变!)

根本原因似乎是midl中的错误,如下所述:

http://support.microsoft.com/default.aspx?scid=kb;zh-CN;220137

引用:

“当存在两个仅因大小写而不同的标识符时,第二个标识符的大小写将更改为反映第一个标识符的大小写。”

因此,作为解决方案,我取消了项目设置中的“注册COM互操作”选项,并添加了构建后步骤

“ $(DevEnvDir).... \ SDK \ v2.0 \ Bin \ tlbexp” $(TargetFileName)/名称:“ $(ProjectDir)Names.txt”%windir%\ Microsoft.NET \ Framework \ v2.0.50727 \重新加气$(TargetFileName)

名称文件包含定义如何进行大小写化的条目。就我而言,它仅包含一行:

ID

最好的祝福

伯恩德·里特

使用/ names为我解决了这个问题。


sha*_*oth 4

您可以使用导入重命名属性来显式重命名属性。假设你有时会变成,有时会变成。始终拥有并使用重命名,如下所示:propAPropApropBPropBPropAPropB

#import <library> rename( "propA", "PropA" ) rename( "propB", "PropB" )
Run Code Online (Sandbox Code Playgroud)

请小心使用它 - 它会导致简单的文本替换,该替换适用于在类型库中遇到的任何标识符。在某些情况下,它可能会导致难以调试不需要的副作用。