Joshua Chini

I added a Nuget package to an application recently and when I tried to run the app I got the following error message.

“Unhandled exception: System.IO.FileLoadException: Could not load file or assembly ‘application name, version=4.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a’ or one of its dependencies. Strong name validation failed.”

It turns out the Nuget package was not strong-named. This is becoming more and more common with Nuget packages. There is some controversy as to whether assemblies should be strong-named. I am not going to discuss whether or not you should be using strong-named assemblies, but you can read the Microsoft documentation to see some of their use cases. The company I currently work at uses strong-named assemblies and so I had to deal with this issue. I had a couple options:

• I could look for a strong-named version on Nuget, which I did and there wasn’t one
• I could find a replacement library that performed the functionality I needed
• I could pull down the source code since it was available on GitHub and strong-name the library myself
• I could disassemble the DLL with ILDASM and sign it. You can find instructions here on how to do it.

Honestly I didn’t like any of those options. Pulling down the source code or disassembling the DLL meant I lost the benefits of Nuget notifying me when there was a new update and upgrading the library became a manual process. I wondered if there was another way so of course I turned to Google and StackOverflow. I came across this comment on a StackOverflow discussion suggesting to use StrongNamer. StrongNamer will automatically add strong names to referenced assemblies which do not already have a strong name. This will allow you to reference and use NuGet packages with assemblies which are not strong named from your projects that do use a strong name.

I added the StongNamer Nuget package to my project. I rebuilt the solution and started the application and everything worked. I didn’t get the strong name validation error. One thing to note is that it uses its own generated key pair which is stored in the packages folder. In our environment we whitelist known keys so this self generated key will need to be replaced before deploying to our server environment.

References

• How to Assign a Strong Name to an Unsigned 3rd-Party Assembly
• Sn.exe (Strong Name Tool) Documentation
• Strong Names Explained
• Giving a .NET Assembly a Strong Name
• Still Strong-Naming your Assemblies? You do know it’s 2016, right?
• StrongNamer Nuget Package
• Replace Public Key Token Utility
• Creating and Using Strong-Named Assemblies