Signing my assembly with a strong name stops it from working

Question

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.

Answer 1

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 under Assembly value of HKEY_CLASSES_ROOT\CLSID\{YOUR_GUID}\InprocServer32 and 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\Fusion could 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.

Answer 2

The error code ix 0x80131040. That's a code that matches a .NET exception, a very common one.

The located assembly's manifest definition does not match the assembly reference.

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.