Home/ Questions/Q 1012737
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T09:59:29+00:00

I’m trying to resolve the following problem: [.Net 2.0, CLR 2.5.something, 64 bit machine,

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0