Could Not Load the Assembly Because the Assembly Wasn't Signed

I was struggling for a few hours trying to get the Microsoft.Framework.Configuration code to run. It wouldn't because it kept complaining that:

FileLoadException was unhandled

As unhandled exception exception of type
'System.IO.FileLoadException' occurred in mscorlib.dll
Additional information: Could not load file or assembly
'Microsoft.Framework.Configuration.Abstractions,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or
one of its dependencies. A strongly-named assembly is
required. (Exception from HRESULT: 0x80131044)

The wasted hours came because I didn't scroll down in the dialog to see the last two lines of the error (for which I feel a little annoyed at myself). It was complaining that it couldn't load the assembly, and I kept trying to debug why the assembly wasn't being found. Except it was being found, just not loaded because it wasn't signed. The group working on this library made a mistake and failed to sign the assembly. As soon as saw the last two lines of the error, I immediately knew what was going on.

I've written about this exact problem in my book. Quoting from  my book, The Reddick C# Style Guide:

An assembly that has strong name can only reference other assemblies with strong names.

And a little further in the book:

⊗    There may be cases where a reference is needed to a required library has not been given a strong name, and there is no way of adding one. There is no other solution than not signing the assembly. If possible, though, work on acquiring a version of the library that has a strong name.

The simple solution to get the code working was to go into the Project Properties of my project and uncheck the "Sign the Assembly" check box on the signing tab. A more complex solution, since the library is open source, would be to get the sources and build it myself, signing the assembly. The best solution is to get the maintainers to sign the assembly so everyone doesn't run into this problem. Unchecking the "Sign the Assembly" check box has the drawback that it causes the Code Analysis CA2210 warning. It also leaves the assembly unsigned, which is a worse problem.

The reason why you want to sign an assembly is that if the private key is kept private, it prevents someone from making unauthorized changes to the assembly. When a program links to the library, it does it in a way that if the bytes of the assembly are changed in any way without re-signing it with the private key, .NET will not load the assembly. This prevents malware from being added to the library and passing it off as legitimate.