使用强名称签署我的程序集会使其无法工作
我的一位同事在 VB.net 中创建了一个程序集，以便通过 COM 互操作与 JScript 一起使用。该程序集过去运行良好，但我们对其进行了签名，现在它似乎只能在 Windows 7 计算机上运行。我测试了 2 台 Windows 7 机器和 2 台 Windows Vista 机器。
当我们对程序集进行签名并尝试在 JScript 中实例化 ActiveX 对象时，会返回一个错误，没有消息，只有一个数字：
错误：
错误号：-2146234304
在 Google 上搜索错误号并没有返回太多结果。
如果我们从程序集中删除强名称，它就可以正常工作。关于可能出现什么问题有什么想法吗？不确定它是否有什么不同，但程序集正在使用 VS 2010 进行编译和签名。
A colleague of mine created an assembly in VB.net for use with JScript via COM interop. The assembly used to work fine, but we signed it and now it only seems to work on Windows 7 machines. I've tested 2 Windows 7 machines and 2 Windows Vista machines.
When we signed the assembly and we try to instantiate the ActiveX object in JScript, an error is returned with no message and only a number:
Error:
Error number: -2146234304
A search on Google for the error number didn't return much.
If we remove the strong name from the assembly, it works just fine. Any ideas on what could be the problem? Not sure if it makes a difference, but the assembly is being compiled and signed with VS 2010.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您是否在程序集签名后重新创建了 COM Interop？如何注册新版本的程序集？您是否清除了 Internet Explorer 的缓存？
一般来说，错误 -2146234304 (0x80131040) 意味着
FUSION_E_REF_DEF_MISMATCH：“名称为 [yourAssembly] 的找到的程序集的清单定义与程序集引用不匹配”。因此，您必须更新使用签名程序集的程序集清单。您应该了解它在您的情况下到底意味着什么。对程序集的引用也保存在HKEY_CLASSES_ROOT\CLSID\{YOUR_GUID}\InprocServer32的Assembly值下，而不仅仅是在真实清单中。您可以尝试调查 Fuslogvw.exe（程序集绑定日志查看器）的问题) （或 http:// msdn.microsoft.com/en-US/library/ms229864(v=VS.80).aspx)。之前可能需要对 HKLM\Software\Microsoft\Fusion 下的注册表进行一些更改（例如 EnableLog、LogFailures，
如果您无法以发布项目链接的方式解决问题，则可能会用于重现您的问题。
Do you recreated the COM Interop after the signing of the assembly? How you register the new version of the assembly? Do you cleared the cache of Internet Explorer?
In general the error -2146234304 (0x80131040) means
FUSION_E_REF_DEF_MISMATCH: "The located assembly's manifest definition with name [yourAssembly] does not match the assembly reference". So you have to update the manifest of assembly which use your signed assembly. What it means exactly in your situation you should find out. The refence to the assembly are saved also underAssemblyvalue ofHKEY_CLASSES_ROOT\CLSID\{YOUR_GUID}\InprocServer32and not only in the real manifest.You can try to investigate the problem with respect of Fuslogvw.exe (Assembly Binding Log Viewer) (or http://msdn.microsoft.com/en-US/library/ms229864(v=VS.80).aspx). Some changes in registry under
HKLM\Software\Microsoft\Fusioncould be needed before (like EnableLog, LogFailures,If you will not solve the problem in the way you could post a link to a project which could be used to reproduce your problem.
错误代码为 0x80131040。这是与 .NET 异常匹配的代码，这是一种非常常见的异常。
我很惊讶您没有收到相关消息，您可能需要检查您的错误处理代码。无论如何，您遇到了一些 DLL 地狱，CLR 正在查找一个程序集，其 [AssemblyVersion] 或 PublicKeyToken 与用于构建代码的引用程序集不匹配。鉴于这与强命名程序集相关联，您可能在构建代码之后签署了该程序集。在这种情况下，只需从项目中删除程序集引用并将其添加回来，现在选择强命名程序集，即可解决问题。
但无需猜测，Fuslogvw.exe 实用程序会告诉您到底出了什么问题。首先运行它以跟踪绑定尝试及其失败的原因。
The error code ix 0x80131040. That's a code that matches a .NET exception, a very common one.
I'm surprised you don't get a message for it, you might want to review your error handling code. Anyhoo, you've got a bit of DLL Hell going on, the CLR is finding an assembly whose [AssemblyVersion] or PublicKeyToken doesn't match the reference assembly that was used to build the code. Given that this is associated with a strong named assembly, you might have signed the assembly after building the code. In which case simply removing the assembly reference from your project and adding it back, now selecting the strong named assembly, will fix the problem.
But no need to guess at this, the Fuslogvw.exe utility will tell you exactly what is going wrong. Run it first to get a trace of the binding attempt and the reason it failed.
使用 dependency walker 在有问题的计算机上打开已签名的 dll。它应该告诉你为什么 dll 无法加载。它可能依赖于 Windows 版本之间不同的 dll，这在签名后更成问题。
Use dependency walker to open your signed dll on the problematic machine. It should tell you why the dll can't be loaded. It could be dependent on a dll which is different between windows versions, which is more a problem after signing.
安迪，不确定这是否相关。那里的解决方案说：
我忘记更新 adxloader.dll（来自 \Add-in Express 中的新版本）
.NET\Redistributables) 在路径中 - 我猜它已经更新了......
Andy, not sure if this is relevant. The solution there says:
I forgot to update the adxloader.dll (from the new one in \Add-in Express
.NET\Redistributables) in the path - I guess it's been updated...
你的数字看起来非常像整数范围的开头！
也许你有一个转换错误，或者你试图增加一个非常大的数字，如果它达到最大值（+2,147,483,647），它就会从−2,147,483,648开始向后计数
只是一个猜测！
your number looks very much like the beginning of the integer range!
maybe you have a casting error, or a really huge number you're trying to increment and if it reaches the maximum (+2,147,483,647) it starts counting backwards from −2,147,483,648
Just a guess!
您是否正在使用 Microsoft Enterprise Library 代码块？我发现这个问题是由于人们在编译代码时没有添加对正确签名库的引用而出现的。
这里有更多后台（如果您使用的是 EnterpriseLibrary）。
Are you using the Microsoft Enterprise Library code blocks at all? I have seen this issue pop up with folks not adding a reference to the correct signed libraries when they compile their code.
Here's some more background if you are using EnterpriseLibrary.
尝试从工作 XP 配置（或从 Vista 盒子）对程序集进行签名。 Windows 7 不支持 CAPICOM，因此无论签名工具如何对程序集进行签名，都可能无法向后兼容 Vista。现在，我看到 CAPICOM 工作得很好，但我也看到它无缘无故地失败，“不受支持”意味着如果您尝试致电，这就是您从 Microsoft 支持部门获得的信息。
Try signing your assembly from a working XP configuration (or from the Vista box). CAPICOM is not supported in Windows 7 so whatever the sign tool may be doing to sign your assembly may not be backwards compatible with Vista. Now I have seen CAPICOM work just fine, but I have also seen it fail for no reason, and "unsupported" means that's what you get from Microsoft support if you try to call.
转到 .Net Framework 配置控制台并使用计算机上的运行时安全策略设置。
Go to the .Net Framework Configuration console and play with the Runtime Security Policy settings on your machine.