17

{"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!

Community
  • 1
  • 1
Pantelis
  • 2,060
  • 3
  • 25
  • 40

5 Answers5

28

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    The .sln file does not contain any assembly references. If you see a null PublicKeyToken in the project file then you still have a reference to the unsigned assembly. Editing it won't help, you must pick the right file. Pretty hard to guess why you are having a problem getting this right. Ask a team member to look over your shoulder while you re-add the assembly reference, he might see you making a mistake. – Hans Passant Jan 30 '14 at 16:32
  • well it actually does ` ..\Signed Third-Party Assemblies\MahApps.Metro\MahApps.Metro.dll ` I just noticed thought, that the assembly's PublicKeyToken and Version are lost after signing it. Thats why I manually added the `PublicKeyToken` in the .csproj file. I use Sn.exe to sign my assemblies, first I disassemble them with ildasm and then re-assemble them by including my public/private keypair. – Pantelis Jan 30 '14 at 16:38
  • Sorry I meant the .csproj file! – Pantelis Jan 30 '14 at 16:39
  • The Include attribute is definitely wrong, it should be the fully qualified assembly name (like Include="MahApps.Metro", Version=1.0.0.0, Culture=neutral, PublicKeyToken=8e7fe144c235f5c2, processorArchitecture=MSIL"). The re-assembly step is important, you should not have left that out of the question. Something went wrong there, it seems the IDE can no longer recognize the assembly correctly. Ask another question about it and carefully describe the exact command lines you used. – Hans Passant Jan 30 '14 at 17:10
  • The include attribute was auto-generated after re-adding the signed reference. Like I previously mentioned, somehow after signing the assembly, it's Version and PublicKeyToken got lost. The command I used on the visual studio command line to reassemble the disassembled binary was: `ilasm /dll /key=strongNameKeyPair.snk /MahApps.Metro.il`. I'll start a new smaller project and try to reproduce the exception and post the question again. Thank you for your time. – Pantelis Jan 30 '14 at 18:12
1

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

habakuk
  • 2,712
  • 2
  • 28
  • 47
0
  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
AstroCB
  • 12,337
  • 20
  • 57
  • 73
tomt
  • 1
0

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.

Ed Ajaz
  • 11
  • 1
0

My problem fixed by moving my solution from remote drive to local drive.

meralon
  • 9
  • 4