How can I edit the "Public Key or Token" field of the Manifest embedded in a DLL or EXE file?

Question

I'm trying to resolve the following problem: [.Net 2.0, CLR 2.5.something, 64 bit machine, all DLLs and EXEs appear compiled for "Any CPU" according to corflags ]

I maintain a legacy application which uses a 3rd party DLL. Out of the blue (as far as I can tell) the functionality depending on the DLL stopped working on one of the machines its deployed at, with the following error:

Could not load file or assembly 'Interop.Merge70, Version=7.0.0.0, Culture =neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

I've viewed the manifest of the DLL as well as the AssemblyRef (used the ildasm tool) in the application's exe file, and the single difference I could find is that the DLL is strongly-signed(?) but according to the AssemblyRef the DLL is unsigned. Now, putting aside the fact that if this is the problem -how did this work till now? (as I only have the user's word for that ;-) )

How can I edit the app's manifest to change the AssemblyRef to be signed with it's public key as appears in the DLL's Manifest? (Also, as scarily enough I haven't got the code for the legacy version, I'm ideally looking for both exe-editing solution as well as something for VS2008 for the current version of the app)

Update turns out that in the current version -the one I do have the code for-the "key or token" field in the code that uses the 3rd party , contains the correct token as extracted by "sn -Tp 3rdparty.dll".. but the same error is thrown when running ... What am I missing here?

Answer 1

You have to recompile the library and sign it during compilation or use delay-signing (but I not ever used that).

From the looks of it, this is a TLBEXP generated library which excepts options to sign the code.

If you do not have the original key, you will have to resign all your assemblies.

Answer 2

If you haven't got the source then you can do this with ILDASM followed by ILASM: in the ILASM step, provide the desired private key.

However, this assumes you have the private key that corresponds to the public key token you want to give the binary. If this is missing (which I guess it is, if the source code has gone) then you'll need to pick another private key to sign with.

If you change private keys then you'll also need to recompile any code that references the assembly, because by changing the private key, you'll change the public key token (and end up with the original error).

Edit: "What am I missing here?" - are you sure the right binary is being used at run time? If you turn on logging via fuslogvw.exe, you should get a more detailed exception.

Answer 3

The following solved the problem :

in the current version I've added the DLL as recommended by vendor -which is as Com+ library rather than standalone DLL. This made the current version functional. I then took the 3rd party DLL which was copied as part of the build and placed it instead of the DLL in the legacy version. Problem solved.... Thanks to all for their helpful answers, and references to useful tools. I've sure learned a bit about troubleshooting :)