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

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...

Answer 2

hi,

your number looks very much like the beginning of the integer range!

Signed: −2,147,483,648 to +2,147,483,647, -(2^31)~(2^31-1)

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!

Answer 3

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 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

Go to the .Net Framework Configuration console and play with the Runtime Security Policy settings on your machine.

Answer 8

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.