CODEWITHSUNDEEP
.netmanifestilstrongnamedisassembly
Pantelis
Pantelis

Reputation: 2070

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

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

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!

Upvotes: 17

Views: 52449

Answers (5)

meralon
meralon

Reputation: 9

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

Upvotes: 0

habakuk
habakuk

Reputation: 2771

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

Upvotes: 1

Ed Ajaz
Ed Ajaz

Reputation: 11

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.

Upvotes: 0

tomt
tomt

Reputation: 1

  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

Upvotes: 0

Hans Passant
Hans Passant

Reputation: 942508

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.

Upvotes: 28

Related Questions