I made a c# application that uses C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0\System.Management.Automation.dll
I also copied the dll to my bin folder. It works fine, but if I copy the bin folder to another machine and run the executable I get this error:
************** Exception Text **************
System.IO.FileLoadException: Could not load file or assembly 'System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
File name: 'System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
Note: I'm not signing the assemblies at all. Also I do not want to disable security by modifying the registry keys. I just want to fix it properly. Any ideas how to fix this problem without globally registering the dll?
Updates: I tried copying the whole visual studio project over to the other machine. It's not working on windows 7 while it is working on windows 8.
You can turn strong-name validation on and off for an application only if the bypass feature is enabled for the computer. If the bypass feature has been turned off for the computer, strong names are validated for all applications and you cannot bypass validation for a single application.
You can turn off strong name validation for an assembly by using the sn.exe utility that ships with the framework. This is helpful if you want to add an assembly to the GAC that is delay signed.
For me, the problem was a NuGet package without a strong name. The solution was to install StrongNamer from NuGet, which automatically adds a strong name to all referenced assemblies. Just simply having it referenced in the project fixed my issue.
You can remove the strong reference to the assembly in your app.confg by changing
System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
to
System.Management.Automation
But I would suggest getting more information about exactly what is wrong, using Fuslogvw (which can be copied onto your destination server, along with a support dll).
This will show you exactly where the application is probing for dll's and what is causing the issue. Maybe you have another dll you need to add to your bin folder, or maybe the GAC is winning out on another dll.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With