Why would you still get "Strong name validation failed"?

There are not many web pages mentioning this so I would just post this so it comes up in search. Having personally spent 4 hours tracking this little thing down, I would want anyone else to go through same :).

So… if you are using delay signing, you will need to run the following command so you can still debug from Visual Studio.Net:

sn -Vr *,[public key token]

Apparently if you are using Vista 64-bit it just won’t work! You will still keep getting error something like,

Could not load file or assembly ‘[Your file], Version=, Culture=neutral, PublicKeyToken=[public ket token]’ or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

You can try viewing Fusion log, cleaning solution, rebooting machine, watch FileMon, run Process Explorer, rebuild everything 10 times… but it just won’t work. Infect if you try removing signing and if your app is WPF 3.5 then you might even get even more weird errors like

Could not create an instance of type ‘StaticExtension’

The solution is hidden in a one liner in Dan Wahlin’s blog:

If you’re running a 64-bit installation of Vista you’ll need to use the sn.exe located at C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sn.exe

I’m pretty sure tons of developers adopting shiny 64-bit OS are/would run in to this. The root cause here is sn.exe designed for 32-bit doesn’t error out instead it happily lets you know that “Verification entry added for assembly ‘*,*‘” successfully! It’s not! So I also filed a bug in out Connect web site. Please vote to make 64-bit world a better place!

Comments (30)

  1. Thank You says:

    Thank you for posting this….It worked for me.

  2. Thank You says:

    Thank you for posting this….It worked for me.

  3. Jimmy says:

    Didn’t work for me. I get the "Verification entry added for assembly" message, but then it still doesn’t work. I also tried to verify with -v, and I still get message saying verification failed. Are there any suggestions for how to debug this?

  4. Some Guy says:


    Just saved me a huge amount of trouble.  😀

  5. Charlie says:

    Thanks for saving me from hours of trouble

  6. Xin says:

    Thanks a lot, it works for me too

  7. Mark says:

    Thanks, this helped a lot. One thing, it isn’t that the 32 bit version doesn’t work on x64. It just writes to the 32 bit registry hive so it will work if your main process that is trying to load the assembly is a 32 bit process. Otherwise, if it is a 64 bit process, then you would need to have the entry in the 64 bit registry hive.

  8. Nicholas says:

    Thank you so much. I wasted hours trying to figure out why skipping strong name validation wasn’t working for my assembly. It’s because it was a 64-bit assembly!

  9. Craig says:

    Thanks as so many other have said! I spent about 2 hours on this until I found your post :o)

  10. Jay says:

    thank you for the info, I installed vmware with xp as guest os and tried to work around as I could not resolve the problem, untill I stumbled accross your post…

    thanks again for sharing

    one happy 🙂 Jay

  11. Matt says:

    It seems that the converse is true here too – if you’re on a 64-bit machine and you want to skip strong name validation for a 32-bit process, you have to use the 32-bit version of sn.exe to do this.  Running the 64-bit version against a 32-bit process did not resolve the problem for me.

  12. Dave says:

    Bless u man…u saved me alot of time

  13. ak says:

    Really helpful. Wasted many hours on this 🙁

  14. wout says:

    Thanks a lot, works on Windows 7 64-bit as well!


  15. magimax says:

    Thanks a lot, after I have already wasted some time, this saved me. (WIN7 64bit, VS2008)

  16. Hao says:

    Thanks a million, man. I have spent almost an entire day trying to figure this out until I came across this post!

  17. Dev says:

    thanks so much! was having this issue on Win7 for the past few hours and was pulling my hair out, I was using the one in bin rather than binx64 (arghhhh!!!)

  18. Swati Jhawar says:

    Hey Man!! Thanks alot, I was facing this issue from long and as I googled I got ur post the first and it really gave solution in 10 secs!! Awesome 🙂

  19. Chris says:

    Thanks for posting this, helped me when I was stumped.  I guess the 32bit version of sn.exe on a 64bit box still works for managed apps marked as 32bit only.  But it sure is confusing.

  20. Chandrashekar says:

    Thanks a lot !! Worked for me.

    (Win Server 2008 64bit + VS 2008 SP1)

  21. JustinRo says:

    WIN7 64bit, VS2010.  This didn't quite work, but it put me on the right path.  With VS2010 and .NET 4.0 there's now 4 sn.exe's: 32 bit .net2, 64bit .net2, 32bit .net4, and 64bit .net4.  I had to be sure to call the 64bit, .net4 sn.exe

  22. TomoLondon says:

    Cheers mate that saved me. Had been trying different stuff for almost an hour!

  23. Graham Pye says:

    Thanks from me too – I've been chasing this problem for days until I realised that even though sn was telling me I had an exception for my EXE it was a 64-bit exception and not a 32-bit exception.

    Would it be too big a deal to have one version of sn.exe that updated/displayed from all the registry hives?

  24. cyclic says:

    I had to change the project settings from Any CPU to x86, then it worked!

  25. Lukalong says:

    Nice one, I was having the same problem – it had me baffled.

  26. vsha041 says:

    That solved my problem. (64 bit OS users) But just remember to use the full path "C:Program FilesMicrosoft SDKsWindowsv6.0ABinx64sn.exe" -Vr *,a8571041c8aa085d instead of "sn" …..

  27. Sreekanth says:

    That solved my problem as well. Thank you.

  28. Svetovid says:

    I have such exception when I run unit test in VS 2012, whereas in VS 2010.

    Do you have any ideas?

  29. Patrick says:

    Thank you. My head, and the wall, appreciate it.

  30. Michal says:

    Thank you very much for this post, it saved my life.