Question

我目前正在与一些遗留代码作斗争（我真诚希望将在最近的将来退役）。不幸的是，目前仍有一些地方需要进一步向下游接收ADODB.Recordset对象。

导致问题的解决方案包括需要引用ADODB COM库的多个程序集。在所有此类程序集中，使用Visual Studio（最初为2013，随后是2015）添加了引用（对ADODB V6.1），并在csproj文件中生成以下元素：

<COMReference Include="ADODB">
  <Guid>{B691E011-1797-432E-907A-4D8C69339129}</Guid>
  <VersionMajor>6</VersionMajor>
  <VersionMinor>1</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>tlbimp</WrapperTool>
  <Isolated>False</Isolated>
  <EmbedInteropTypes>False</EmbedInteropTypes>
</COMReference>

不幸的是，即使Guid是相同的，并且版本信息是相同的，也有一些地方将引用的类型解释为不同，导致在构建时出现如下错误：

[SomeFile] .cs（54,17）：错误CS1502：'Rhino.Mocks.Interfaces.IMethodOptions.Return（ADODB.Recordset）'的最佳重载方法匹配有一些无效的参数[SomeProjectFile.csproj] [SomeFile] .cs（54,25）：错误CS1503：参数1：无法从'ADODB.Recordset [[AssemblyRoot] \ _obj \ debug \ Interop.ADODB.dll]'转换为'ADODB.Recordset'[SomeProjectFile.csproj ]

在我看来，几乎就像Visual Studio / MSBuild变得混淆并且认为引用是针对COM库的不同（因此可能不兼容）版本。我看不到的是为什么。有什么建议吗？

Answer 1

我刚刚进行了头脑风暴......结果证明是正确的。其根本原因似乎是非常不喜欢的代码签名功能。其中一个包含ADODB参考的程序集（实际上作为我们产品的一部分分发的程序集）已经签署。构建失败的程序集（包含第一个程序集的单元测试）未签名。我的猜测是，即使引用的COM组件在两个地方都是相同的，库引用（可能由幕后的TLBImp.exe生成）在一个地方签名而在另一个地方没有签名导致不匹配和关联构建错误。使用与他们正在测试的程序集相同的密钥对有问题的测试程序集进行签名，这样就可以使部分构建成功。

为什么两个程序集中的相同COM引用可能会在构建时导致CS1502和CS1503错误？

1 个答案: