|Message||"Strong name validation failed."|
|Comment||Strong name validation failed|
|Description||The source of the error code is .NET CLR.|
|Error Code||5146 (0x141a)|
This problem is related to Strong Name Validation. Open your AssemblyX in Ildasm.exe(C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin). Note its
PublicKeyToken, lets say
pkt123 for an example. Now open VS Command prompt in administrator mode and run the sn.exe command. Such as:
sn -Vr *,pkt123
Build your solution again and everything should be fine by now.
But if not and you receive same error now also, then you need to run a different version of sn.exe. To locate that, go to Visual Studio command prompt.
c:\Program Files(x86)>dir /s sn.exe
It may take 5-10 seconds and should give a list of sn.exe files. Go to the path and execute the sn.exe, required or belongs to you, as shown above. If not sure which one to execute, execute all the sn.exe. That should and must solve your problem. If not, let me know and let me carry forward the RnD again.
Open the command prompt as administrator and enter following commands:
reg DELETE "HKLM\Software\Microsoft\StrongName\Verification" /f reg ADD "HKLM\Software\Microsoft\StrongName\Verification\*,*" /f reg DELETE "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification" /f reg ADD "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification\*,*" /f
The root cause to the problem is that I use the x64 platform to build the sln and to run test case with x86 test setting.
Just use the correct test setting platform to run test case:
Open the command prompt as administrator and enter the following command:
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sn.exe" -Vr <dllpath>
Pay attention that the argument are case sensitive. Source with more details: http://blogs.msdn.com/b/keithmg/archive/2012/03/20/strong-name-validation-failed-exception-from-hresult-0x8013141a.aspx
Finally I was able to fix my issue. This is what I does;
open my .csproj file
search for System.Management.Automation reference.
Replace that with the following
<Reference Include="System.Management.Automation" />
These steps fixed my issue
Is the one the code runs on a "development" machine where you might have run "sn.exe -Vr AssemblyName.dll" at some stage which would allow you to use a delay signed assembly as if it were fully signed. When you transfer the delay signed assembly to another machine and run it, it will fail strong name validation because it is not fully signed.
I had the same problem, and the link below helped me...
VS.NET 2005: Code coverage for signed assemblies I am currently working on an application using VS.NET 2005, and because all the TDD tools like unit testing and code coverage are available I started to use them.
When I started code coverage on my signed application I got the following exception:
Test method X threw exception: System.IO.FileLoadException: Could not load file or assembly 'Y, Version=220.127.116.11, Culture=neutral, PublicKeyToken=Z' or one of its dependencies. HRESULT: 0x8013141A Strong name validation failed. ---> System.Security.SecurityException: Exception from HRESULT: 0x8013141A Strong name validation failed at X.
Not so strange if you think about it. Assembly is signed, code coverage needs code instrumentation, means modifications of the assembly, resulting in incorrect assembly so the validation failed.
Solution is to resign the assembly after instrumentation.
If you open the localtestrun.testrunconfig file (or something similar) in your solution items (double-click it), you can enable resigning in the Code Coverage section. This solves the problem.
Thank you for reporting this issue. The System.Runtime.* analyzer assemblies uploaded to nuget are indeed only test-signed, and hence cause the assembly load failures. We are working uploading newer nuget packages for System.Runtime.Analyzers and System.Runtime.InteropServices.Analyzers which will have signed assemblies.
Meanwhile, you can get the non System.Runtime based FXCop analyzers by installing "Microsoft.AnalyzerPowerPack" from here: https://www.nuget.org/packages/Microsoft.AnalyzerPowerPack/. These do contain all signed assemblies and should work fine.
I'll post an update on this thread once we have uploaded signed System.Runtime analyzer packages.
Sorry for the inconvenience and thanks again for reporting it!
Since I'm not able to comment on the only answer to this I wanted to make sure that other users that came upon this answer as I did do not make the same mistakes other may have. According to the MSDN documentation for the strong naming utility, using the Vr(signature skipping) switch can cause malicious assemblies to load and should only be used in DEVELOPMENT not deployment.
It is also possible to simply disable all signed assembly checking on a particular machine by executing:
sn.exe -Vr *
Use with care, however, as this opens a security vulnerability. We use this on our internal virtual machine that measures coverage for us. Take a look at the usage for
sn.exe as it is possible to narrow the scope of that command.
You might be able to bypass this on development by going into the project settings -> Signing -> and unchecking "Sign the assembly".
I ran into this today while debugging against a source code copy of the Entity Framework.
In my case, I had the same issue with
Visual Studio 2015 and I already had signed the assembly.
I fixed it by this way: Right click on the project which causes the issue -> "Properties" -> "Build" -> Change the value of the "Platform target" field.
I had to change it from
Any CPU to
x86 but I guess that in function of the project and the library which is failing, you should change its value to
SqlDataProvider is a type provider, which means that it contains code that runs at compile time so that it can generate types for you to use at compile time. All parameters to type providers have to be constants that are known at compile time. This is why
resPath needs to be a "literal" (effectively the same thing as a compile time constant).
__SOURCE_DIRECTORY__ doesn't have a trailing backslash so you need to add that:
let [<Literal>] resPath = __SOURCE_DIRECTORY__ + @"\..\packages\MySql.Data.8.0.8-dmr\lib\net452"
With this in place I was able to reproduce your
Strong name validation failed error. Switching to v6.9.9 (marked as the current version) of MySql.Data fixed that for me.
You can remove the strong reference to the assembly in your app.confg by changing
System.Management.Automation, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35
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.
Place this code in your app.config
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.2"/> </startup>
If it would not work then download Crystal Report Runtime from this link http://downloads.businessobjects.com/akdlm/crnetruntime/clickonce/CRRuntime_32bit_13_0_1.msi
If again Crystal Report create some problem then right click on your project, open Properties, open Debug tab and check option Enable Unmanaged code debugging.
Your assembly is probably either delay signed or test key signed, and it looks like PowerShell only allows fully-signed assemblies to be loaded (i.e. it ignores the skip verification setting). This would explain why sn.exe says the assembly has a valid strong name signature when it technically doesn't. (You can find out if the assembly actually has a valid signature, even if it's registered for verification skipping, by running
sn -vf instead of
I think the major source of your confusion stems from a mistaken assumption about how verification skipping works. Registering an assembly for verification skipping is not a guarantee that the assembly's strong name signature will never be verified. Verification skipping is specifically intended to allow delay signed and test key signed assemblies to work seamlessly in situations like these, but nothing is stopping someone (like PowerShell) from overriding it and forcing verification anyway.
The Entity Framework source code is configured to produce delay-signed assemblies (which means they're marked as "should be signed in the future with the official key"). The official instructions at Entity Framework's GitHub page show how to disable strong name validation (run the
build /t:EnableSkipStrongNames), so that you can use the delay-signed assemblies without anyone having to release their private key. This is sufficient for development systems.
If you intend to release a product relying on your custom-built modified Entity Framework DLLs, you should generate a new key, and modify the EF source code to use that new key.
I figured it out--portions of the install need .NET 3.5 which is not standard on Server 2012. To enable this on Server 2012, you need to put the 2012 disk in, and type the following command in the shell prompt:
dism /online /enable-feature /featurename:NetFX3 /all /Source:d:\sources\sxs /LimitAccess
I encountered this today and stumbled across http://timgeerts.blogspot.co.uk/2009/08/strong-name-validation-failed.html, which seems to be the solution.
Option 1) Turn off code coverage (in VS 2010, go to Test Settings -› Data and Diagnostics -› Untick the "Enabled" box next to Code Coverage).
Option 2) Add the signing key file to the code coverage configuration (in VS 2010, go to Test Settings -› Data and Diagnostics -› select Code Coverage and click on "Configure" at the top. This corresponds to the "keyFile" attribute for the CodeCoverage tag in the .testsettings file.)
In VS 2012, code coverage is enabled by default. It can be disabled through a .runsettings file with an appropriate exclusion. See http://msdn.microsoft.com/en-us/library/jj159530.aspx for more information and a sample file. For option 2, although there doesn't seem to be an explicit setting available in the .runsettings file, the right thing seems to happen automatically with regard to signing (YMMV). However, if you're referencing a VS 2010 .testsettings file then it will need editing as above.
The SN.EXE is Missing in Newer versions of Visual Studio. In Visual studio 2012, we must use "Developer command prompt for Visual studio 2012". Then Run the command "sn".
Syntax: sn -Vr *,2d58152b8e842be2
where "2d58152b8e842be2" is the public key token shown in the Error message. Somehow this alone did not solve my problem.
If you are running .Net 4 in VS2010, then you may need to add the following to your .config file (configuration section):
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup>
If this doesn't work, then you need to upgrade to Crystal Report for VS2010 from this link.
This question was already asked and discussed in a duplicate post here: getting exception after webjob sdk code fork for public class ServiceBusTriggerAttribute
This issue was recently discussed in the public repo here. I don't think trying to subclass the attribute is the way to go. I suggested some alternatives in the github issue. You're getting the above exception because all the WebJobs SDK assemblies are delay signed (in project settings). They need to be fully signed for use.
So, it seems that Visual Studio for Mac doesn't understand the csproj/msbuild flag:
And sgen is the thing that won't let me get on with my work day. So let's replace sgen with our own version that does nothing!
sgen is located on my Mac at:
I made a simple .NET console app in VS4mac that does nothing, and copied it to that dir, replacing the original sgen.exe
I can now compile my assembly, resulting in a warm feeling of bliss marred only slightly by the worry that I've done something I probably shouldn't have.
If anyone knows how to fix this properly, I'd be much obliged.
That helped me figure out what's going on. This is a msbuild vs xbuild bug:
xbuild WebServicesNotWorking.sln /p:Configuration=Release (Works) msbuild WebServicesNotWorking.sln /p:Configuration=Release (Your error).
Cd "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"
sn –Vr **AssemblingX** name (without dll extension), **PublicKeyToken**
Rebuild the solution. And it should be solved.
If your outlook add-in is signed using a strong name key then any external libs that you reference will also need to be strong name signed.
I've had a similar problem to yours in the past where 3rd party libraries were not signed with a strong name.
After doing a bit of searching around I came across this Microsoft Support article that provides a resolution.
When you use Microsoft Visual Studio 2005 to create add-ins, smart documents, or smart tags, you may experience the following symptoms:
- The add-ins, the smart documents, or the smart tags cannot be loaded in any Microsoft Office application.
- The add-ins, the smart documents, or the smart tags do not run in any version of Microsoft Office.
and their resolution:
To resolve this problem for Visual Studio 2005 developers, a redistributable version of the update for Visual Studio 2005 is available.
Did you "unlock" the .zip file before unpacking it?
On some OS's, specifically Windows 10, I had to right click on the downloaded zip and click "unlock" before unpacking.
If you then run the .\ConfigureAgent.ps1 it should work.
c:\Program Files\Common Files\microsoft shared\VSTT\11.0\UITestExtensionPackages\ solved the problem. Action was performed on the remote VM.
The tests are up and running.
I got a solution for this issue.
You just have to do is, put the
mono.android.dll in to the
Files\Microsoft SDKs\Windows\v7.0A\bin folder, open a command prompt and do
cd C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin
sn -Vr Mono.Android.dll
gacutil -i C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin
Then build the project.
If you get the error for another DLL like
System.xml.dll etc. then repeat above
procedure for respective DLL.
All the best.......!
The issue we experienced was also with the
ImageList inside the *.resx file (opened in code, not the designer):
<data name="imageList1.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64"> <value> [bunch of binary data here] </value> </data>
We confirmed this was by only deleting the
<data /> tag related to the
ImageList (see above) and then deleting the references in the control's designer:
//initialize this.imageListSuperHeroes = new System.Windows.Forms.ImageList(this.components); //control that references the ImageList this.btnAwesome.ImageKey = "superman.gif"; this.btnAwesome.ImageList = this.imageListSuperHeroes;
Add the image references (use individual images!) of the control from the "Project resource file", rather than the "Local resource" and update the references you removed from your forms.
this.btnAwesome.Image = global::PMPPlus.Properties.Resources.Superman;
That fixed it for us and hopefully this helps move you in the right direction. If not, dig around the *.resx to see which bad
<data /> is screwing you up.
They suggested some workarounds that didn't fit our needs:
I was able to solve this problem doing the following:
On this way, putting the web reference in a project that doesn't reference Mono.Android itself the application was able to release with no problems
The next step is to try to sign the assembly as a strong named one, microsoft provides a guide to do so at this webpage: http://msdn.microsoft.com/en-us/library/xc31ft41.aspx . After you create your keys and successfully complete the procedure you can see if the error still occurs. On a development environment a lot of dll's, assemblies, and protection setting are changed to allow you to execute and debug code. You would need to install a version of the addon with debug symbols and something like the Debugging Tools for Windows for native code or MDbg or coredbg( Lightweight .NET debugger? ) to see what is going on on your reference machine.
Generate serialization assembly prevented you from building.
I got the NameResolutionFailure when selecting Release target because i didn't set the INTERNET permission in the application's options:
It seems that this is active for debug builds since it's used to connect the debugger to the application.
You have to set this yourself in the Release build configuration.
It looks like this is a signing issue. Aspose.Cells is a strong-named assembly, the error you're getting here means the CLR in the test machine is unable to find corresponding public key to verify the .dll's signature. It looks like you'll need to resign the assembly.
If you're getting a strong name validation error on a winmd file, it's typically because you're using a toolset that doesn't understand the .winmd file format.
.winmd files cannot be strong name signed.
In this case, it's possible that the problem is caused because you're trying to strong name sign a component library - C# component libraries produce hybrid .winmd files that contain both windows metadata and C# IL.
Why are you trying to strong name sign your component? Strong name signing is mostly used when putting assemblies into the GAC and .winmd files cannot be inserted into the GAC.
In VS2010, it should be
Test - Edit Test Settings - Local - Hosts
also, you need to check Build - Configuration Manager
Got almost the same error. Was not able to get the SQL installation wizard going, just a error: "managed sql server installer has stopped working" + CLR20r3 + filenotfoundexception. Tried on other Win2012r2 installations, new vanilla install and new install with updates with no success. Solution: Removed windows updates kb2966826-27-28 and then it worked. Link: https://support.microsoft.com/en-us/help/3002547/you-cannot-enable-the-microsoft--net-framework-3-5-feature-on-windows My god - this was not awesome.
Have you tried signing the project(s)? That may remove your error.
Maybe this link about your error will help: https://blogs.msdn.microsoft.com/keithmg/2012/03/20/strong-name-validation-failed-exception-from-hresult-0x8013141a/
or this stackoverflow question: Strong Name Validation Failed
You can right click the project in Visual Studio solution explorer, and Signing on the left and uncheck sign assembly. In your web config you will also need to remove the public key token.
if still not resolved you have to delete or set AllowStrongNameBypass (DWORD) to "1" in the key
On 64-bit computers,
I think the problem is that the way I did it works only on windows 8 since it has a newer version of this dll. To make it run on windows 7:
< Reference Include="System.Management.Automation" />
changed the authentication code to this
SecureString securePwd = new SecureString(); pass.ToCharArray().ToList().ForEach(p => securePwd.AppendChar(p)); PSCredential credentials = new PSCredential(username, securePwd); string shellUri = "http://schemas.microsoft.com/powershell/Microsoft.PowerShell"; WSManConnectionInfo connectionInfo = new WSManConnectionInfo(false, host, 5985, "/wsman", shellUri, credentials, 100000);// timeout is in miliseconds
[Use this solution if you have problems during Testing binaries] I have the same problem as the author. I removed the strong name on the system.management.automation.dll using snremove.exe
snremove -r .\system.management.automation.dll (And remove strong name for all your binaries being used for testing.) http://www.nirsoft.net/dot_net_tools/strong_name_remove.html
It works well now. I do this only because I didnt want to check in my binaries before testing. Once checked in, my binaries are signed by the build and I dont have to worry about strong naming.
Start by reading this background on how DTF works:
When you rename your wrapped CA DLL to .zip and look at it's contents you are likely not going to see your signed DLLs in there.
It's been awhile since I did this but I think it has to do with SfxCA's default build behavior with regard to trying to decide what it should and shouldn't pack. (Say you DLL yes, some other DLL yes, system.dll no ) and I think it takes code signing into consideration. Toggle the CopyLocal (true|false) flag on your reference and rebuild / reexamine using the zip technique.
I was able to solve this, I had downloaded the assembly from nuget, it turns out I had to directly download the dll from their site which turns out to be strongly named.
Found Extensibility.dll in
\Visual Studio Tools for Office\PIA\Common
folder. Copied it to the project folder.
I have VSTO 2010. Added the reference to my project, and the compile error went away. Same version on the error: 7.0.3300.0. VSTO is distributed freely by Microsoft for developers, to create solutions for Microsoft Office, but the license document enclosed with VSTO 2010 doesn't allow you to make copies of it except for your own use. That being said, I would pester Microsoft about the dll, as obviously you need it for your project. Obviously, they should have added a clause to the license to allow distribution of the dll by developers.
After looking through the post suggested by @Mangist, I recognized that the issue was a combination of registry location, and misunderstanding tlbimp.exe 's delaysign flag. This also helped. https://msdn.microsoft.com/en-us/library/aa302324.aspx
First, as my app is a x86 application and most of the libraries are x86, using the x64 command prompts is a bad idea, as any tool that affects the registry will write to the HKLM\Software location. Since these are x86 assemblies, any registry entries regarding them need to be written to the HKLM\Software\Wow6432Node location. This mistake was triggered by what I found regarding tlbimp.exe, as when I was using the x86 command line tools, I was still getting the regasm error, prompting me to attempt the build using the x64 command line tools, which of course also didn't work.
Tlbimp.exe indeed does have an option to delay sign an assembly, and it will do exactly that, but delay signing an assembly DOES NOT AUTOMATICALLY REGISTER THE ASSEMBLY FOR VERIFICATION SKIPPING. Registering an assembly for verification skipping requires use of the sn.exe command with the -Vr option. This adds an entry to the HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification registry key when using the 32 bit sn.exe, and the HKLM\Software\Microsoft\StrongName\Verification registry key when using the 64 bit sn.exe.
It turns out that you can register a single assembly signed with a particular public key for verification skipping, or any assembly that uses a particular public key for verification skipping. A registry entry will be created looking like
Here * is a wildcard, and the hex number is the public key.
This entry is an example of allowing only the MyInteropDll.dll assembly to be skipped from signing verification.
The solution for me then is to ensure that after I make the tlbimp /delaysign call to add a command that registers the assembly for verification skipping since that's not being done automatically.
C:\>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\sn.exe -Vr MyInteropDll.dll
If you have visual studio 2010 in your system then crystall report is not install because there is no any crystal report with visual studio 2010.for open the crystal or .rpt file install the sap crystal report 2010.It willl downloaded from sap object websit.
Can you check what version of
Microsoft.Xrm.Sdk.Workflow library you have referenced in your project. According to the error message, CRM is looking for the
This is a partial answer to your question, it provides the solution for your general problem (submitting to the App Store), but not the one that you have mentioned in the title of the question.
It is possible to use Visual Studio for Windows and to create the package to be submitted (and use Apple's Application Loader to submit it). You need to set the build configuration to Ad-Hoc (not Debug or Release), build platform to iPhone, set your certificates and click Rebuild All, then .ipa file will be generated on both your Windows and Mac and you can use it to submit it to the Store.
this is an annoying issue that can easily be sidestepped for development purposes.
To disable the strong name validating, simply open the visual studio command-line (for example, in Windows 7: Start >> All Programs >> Microsoft Visual Studio 2010 >> Visual Studio Tools >> Visual Studio Command Prompt (2010) )
sn -Vl which will return you a list of all the assemblies registered for strong name validation.
sn -Vr *,idnumberhere to disable the strong name validation for that assembly.
In the case of the error you are receiving (
Failed to open registry key -- Unable to format error message 00000005), this is most often related to permissions: your username may not have the necessary permissions to change strong name validation hence change the permissions on
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA to allow full access to your username as well and all should be fine again:)
Also, ensure that you run the VS command-line with elevated privileges so select
Run as Administrator.
Hope this helps. :)
Let me know if you need more information as well though:)
This error is probably due to error Windows Registry try to modify it or install Intel or AMD OpenCL SDK on your machine, try to create the project again
or Update the include and library paths of the project to load the required information from the OpenCL SDK installed
I had this same exact problem today, and unfortunately, wasn't able to get it to work using sn.exe.
However, a workaround that worked for me was to just use one of Intel's sample programs as a starting project, and modify it from there. (For example the basic capabilities sample)
This Package shows its unsigned so try to use another package but its unsatble version. https://www.nuget.org/packages/EntityFrameworkWithHierarchyId/6.1.0-pre1
I think this has to do with assembly verification. Because you edited it, you need to re-sign it. Because you could have added evil code to the already-verified DLL. Check out this for disabling verification, but I don't think that is a long term solution.
I've done this as we updated to using .NET 4.5 with Unity 3 and Prism. You need to re-sign UnityExtensions in order to use Unity 3.0.XXX.X
Here is a few easy steps that will get you through:
Did you try searching for the error online? Here is the first hit I got for an MSDN blog with a workaround.
You may want to ask the third party to provide a fully signed DLL.
If you are running .Net 4 in VS2010, then you may need to add the following to your .config file (configuration section):
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup>
I've had lots of issues with .NET, LuaInterface, and Lua5.1 interracting on 64-bit machines. Lua5.1 only compiles 32-bit and this requires you to (I believe) build the LuaInterface project as 32-bit as well. Try changing "Project -> Properties -> Build -> Platform Target" to "x86" in your .NET projects.
There is an open source tool for the XrmToolbox called the Early Bound Generator from Daryl LaBar, which is just a wrapper on top of crmsvcutil from the SDK. Save yourself the trouble and use that tool, it has a lot of nice features baked in. Btw, with the latest versions of the toolbox, there is a plugin "store" so you don't even have to download the EBG manually anymore.
User contributions licensed under CC BY-SA 3.0