Could not load file or assembly 'AssemblyName PublicKeyToken=null' or one of its dependencies

15
votes

{"Could not load file or assembly 'AssemblyName, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"AssemblyName, PublicKeyToken=null"}

I'm getting the message in question as an InnerException.Message while trying to debug my application after signing the unsigned third-party assemblies it is using. The weird thing is that I have already signed the assembly shown in the message, the one that can't be loaded.

What could the problem be here? How can I resolve this?

EDIT

Editing to give more information on what I did:

  • Signed all the unsigned third-party assemblies my project is referencing.
  • Disassembled those assemblies to see if they internally reference any external unsigned assemblies (they didn't)
  • Deleted the old unsigned assemblies from the project's reference list, and re-added the newly signed ones.
  • Unloaded the project and edited the reference of the assembly that can't be loaded in the .sln XML-styled file by adding the PublicKeyToken that was missing from the assembly reference.

The assembly that throws the exception, btw the project builds fine it's a runtime exception I'm getting on InitializeComponent() of that assembly, is an open source component with WPF controls (MahApps.Metro). I've found a similar question but none of the answers there fixed the issue.

How to force WPF to use resource URIs that use assembly strong name? Argh!

4
.netmanifestilstrongnamedisassembly

4 Answers

27
votes

PublicKeyToken = null tells you that the CLR is looking for the unsigned assembly. Since you signed them, that's not going to work well and this kaboom is expected.

You will have to rebuild the program so it uses the updated signed assembly and embeds the non-null PublicKeyToken into the manifest. You may have to remove the existing assembly reference and add it back, it isn't clear from the question whether you built the program using an unsigned copy.

Use the Fuslogvw.exe utility if you still have trouble.

1
votes

Maybe one of your "unsigned third-party assemblies" has a reference to another one of your "unsigned third-party assemblies" - so the reference is wrong after you signed them all.

Maybe this tool can help you: https://github.com/brutaldev/StrongNameSigner - it can update the assemblies (it probably also can done by using the command line, but I don't know how).

0
votes
  1. backup all the production dll and files to another folder - just in case to rollback
  2. copy all the production dlls that the current process is running to your local project
  3. reference all these dlls on all the related local projects.
  4. Compile and copy the project dlls out again to try starting the window services.

still not working yet.

  1. backup all the production dll and files to another folder - just in case to rollback
  2. Copy all the new compiled dlls from the local projects and over-ride the dlls to the production folder
  3. start up the window service
0
votes

I noticed you did say you signed the 3rd party libraries, but don't forget to also sign your own assemblies that use the 3rd party libs as well. Most importantly would be the assembly using the signed libs. This was how I recently fixed this issue for myself.

Visual studio is sometimes overly forgiving and allows us to get away with more than we should. Other times? Not so much.

Be sure to clean your project after making the changes as well. Then rebuild the solution. Hopefully that will get you a step further.