How do I debug "strong name validation failed"?

I have a program that works fine on my old Windows 7 computer. I copied its folder to my new Windows 10 computer, (there are no details that require a more complicated installation process,) and suddenly it won't run. Trying to run it on the command line gives me:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'foo, Version=2.0.9.4, Culture=neutral, PublicKeyToken=32c39770e9a21a67' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A) --- End of inner exception stack trace ---

Which tells me nothing useful at all. Either the program "or one of its dependencies" has a problem with its strong name verification, and I don't know which one it is, and for the life of me I can't figure out how to figure out where the problem is!

I've tried FUSLOGVW. There are multiple different versions on this computer, and I've tried each one, one at a time, making sure that they're set to record binding failures to disc, trying to run the failing program, and then refreshing FUSLOGVW. Nothing shows up.

I've tried running sn.exe -v against the program. It tells me:

Failed to verify assembly -- Strong name validation failed.

Which, again, is completely useless, as I have no information regarding what went wrong or why.

I've found a few questions on here with answers about using sn.exe or various registry tricks to disable strong name verification. This is not what I want to do; I want to figure out what the problem is and fix it. And once again, this all worked just fine, with the exact same binary, on my Windows 7 box.

How do I figure out what's going wrong with the strong naming verification on this program?

Assuming the assembly might have been registered for strong name verification skipping on the windows 7 machine, does it stop working there if you use sn.exe -Vu foo.dll to unregister foo.dll from verification skipping? In that case you might have no other choice than to sn.exe -Vr foo.dll on the windows 10 machine to enable verification skipping for that assembly. Did you try copying the assemblies a second time from the windows 7 machine to exclude random corruption from the set of possible answers? Is the assembly delay signed or anything like this? Is a working version of that assembly in the GAC of the windows 7 machine?