How to fix "Referenced assembly does not have a strong name" error

Question

I've added a weakly named assembly to my Visual Studio 2005 project (which is strongly named). I'm now getting the error:

"Referenced assembly 'xxxxxxxx' does not have a strong name"

Do I need to sign this third-party assembly?

Pigtail

stackoverflow.com/questions/1220519 – Excel

This might sound like a silly tip but if you find that your assembly is not getting signed no matter what you do, check your build settings; remember that VS doesn't clear out other architectures (Any CPU, x64, etc) when you rebuild / clean, so you could be looking at an outdated dll from another architecture. – Guglielma

@Guglielma my build keeps telling me that my project is not strongly named, but I have signed it! I have even installed StrongNamer nuget package, but it still complains that the assembly is unsigned. This troubleshooting is one of the most unpleasant things tbh. – Landfall

Answer 1

To avoid this error you could either:

• Load the assembly dynamically, or
• Sign the third-party assembly.

You will find instructions on signing third-party assemblies in .NET-fu: Signing an Unsigned Assembly (Without Delay Signing).

Signing Third-Party Assemblies

The basic principle to sign a thirp-party is to

1. Disassemble the assembly using ildasm.exe and save the intermediate language (IL):

   ildasm /all /out=thirdPartyLib.il thirdPartyLib.dll 
   

2. Rebuild and sign the assembly:

   ilasm /dll /key=myKey.snk thirdPartyLib.il
   

Fixing Additional References

The above steps work fine unless your third-party assembly (A.dll) references another library (B.dll) which also has to be signed. You can disassemble, rebuild and sign both A.dll and B.dll using the commands above, but at runtime, loading of B.dll will fail because A.dll was originally built with a reference to the unsigned version of B.dll.

The fix to this issue is to patch the IL file generated in step 1 above. You will need to add the public key token of B.dll to the reference. You get this token by calling

sn -Tp B.dll 

which will give you the following output:

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.33440
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key (hash algorithm: sha1):
002400000480000094000000060200000024000052534131000400000100010093d86f6656eed3
b62780466e6ba30fd15d69a3918e4bbd75d3e9ca8baa5641955c86251ce1e5a83857c7f49288eb
4a0093b20aa9c7faae5184770108d9515905ddd82222514921fa81fff2ea565ae0e98cf66d3758
cb8b22c8efd729821518a76427b7ca1c979caa2d78404da3d44592badc194d05bfdd29b9b8120c
78effe92

Public key token is a8a7ed7203d87bc9

The last line contains the public key token. You then have to search the IL of A.dll for the reference to B.dll and add the token as follows:

.assembly extern /*23000003*/ MyAssemblyName
{
  .publickeytoken = (A8 A7 ED 72 03 D8 7B C9 )                         
  .ver 10:0:0:0
}

Lecce

Thus is signing the assembly an option, I neither wish to load the assembly dynamically nor to sign it. I know that strong naming is in regards of the Global Assembly Cache (GAC). Despite, I don't want to make my assemblies part of the GAC and neither are they COM-visible. I remember partially remember of something we may do that will allow the use of this assembly without signing it. It is somewhere in the options properties or so. Am I out of track wanting to go that way? – Migrant

You can use unsigned assemblies if your assembly is also unsigned. – Armington

or unsign the other assembly if you have it <warning hack!> – Unrequited

For some reason, I also had to use sn -Vr <public key token> afterwards. – Ari

Although the above steps will work in "most" situations, it's incredibly time consuming and error prone and fails with friend assembly references among other things. Just use this utility to do it all automatically (shameless plug): https://mcmap.net/q/107967/-how-to-fix-quot-referenced-assembly-does-not-have-a-strong-name-quot-error – Banebrudge

@Roel I've detailed the process here delabs.io/the-12th-labor-of-a-net-developer-part-4 – Lusty

if you want to preserve File Version then add /res when build dll ilasm /dll /key=myKey.snk thirdPartyLib.il /res=thirdPartyLib.res – Gloom

Answer 2

Expand the project file that is using the project that does not "have a strong name key" and look for the .snk file (.StrongNameKey).

Browse through to this file in Windows Explorer (just so that you know where it is).

Back in Visual Studio in the project that does not "have a strong name key", do

• Right click on the project file
• Select Properties
• Select "Signing tab" (on the left)
• Click the check box "Sign the assembly"
• Then <Browse> to the .snk file you found earlier

That should do the trick. This solved a problem for me for one project using a form inside another project in the same solution.

I hope it helps.

Awlwort

If I did not want to sign my assembly I would not have signed it from the start! – Agapanthus

If you don't find the .snk-file: Open the project properties (of the project using the project with the "strong name" error), tab Signing. There you will see the file used to sign the project (isn't always a file with the .snk extension). Just copy this setting to the other project. – Carlynne

As MrOli3000 points out, it works ONLY if there is one solution that is missing the strong name key file. If there are multiple projects that would reference the unsigned project, you are better of creating a new strong name key file to avoid any conflicts. In my case, the solution didn't build, and I was going in circles trying to fix. As of VS2017, the format is .pfx and not .snk, but the steps are the same - Right click on the solution and choose properties. From the tabs listed on the left, choose "Signing". Click the check box and select new... provide a name! and Voila! it is done!) – Luannaluanne

what is the password of .pfx file? @Luannaluanne – Norty

Answer 3

I was searching for a solution to the very same problem and unticking "Sign the assembly" option works for me:

(As you may notice, the screenshot comes from Visual Studio 2010, but hopefully it will help someone.)

Quaternion

I don't check this setting in my MVC project. But it's still complaining about one of the dependencies. Is there any other setting for MVC? – Genetic

Answer 4

I have written a tool to automatically strong-name sign assemblies including ones you do not have the source code for or projects that have been abandoned. It uses many of the techniques described in the answers in a simple way without any of the flaws or drawbacks of existing tools or dated instructions.

.NET Assembly Strong-Name Signer

I hope this helps out anyone that need to sign a third-party assembly without having to jump through hoops to get there.

Banebrudge

This was a quick and easy tool. Just added a NuGet reference and a pre-build command to sign 3rd party library missing signature. Thanks! – Gigue

@BrutalDev: Does this work with .NET-Standard-2.0-Projects and the new Project Files as well? I could get it to run with a .NET-4.8 Project that references an unsinged assembly, but not with a .NET-Standard-2.0-Project. In my case I want to add strong signing to the DLL of Scrypt.NET 1.3.0 (Nuget-Package). – Endres

@Endres Sure, it works with any .NET assembly. Just add it as a NuGet package and build, it should still find all the references you use that are not signed and sign them. If you are having issues or need more help just post in a GitHub issue: github.com/brutaldev/StrongNameSigner/issues – Banebrudge

Answer 5

You can use unsigned assemblies if your assembly is also unsigned.

Chittagong

Answer 6

Signing the third-party assembly worked for me:

Referenced assembly does not have a strong name

I've learned that it's helpful to post steps in case the linked article is no longer valid. All credit goes to Hiren Khirsaria:

1. Run Visual Studio command prompt and go to directory where your DLL located.

   For example, my DLL is located in D:/hiren/Test.dll

2. Now create the CIL file using the command below.

   D:/hiren> ildasm /all /out=Test.il Test.dll (this command generates the code library)

3. Generate a new key to sign your project.

   D:/hiren> sn -k mykey.snk

4. Now sign your library using the ilasm command.

   D:/hiren> ilasm /dll /key=mykey.snk Test.il

Humphreys

Your link made the trick! Thanks!And it explains how to create mykey.snk (they other answers don't say how) – Donee

Answer 7

How to sign an unsigned third-party assembly

1. Open up Developer Command Prompt for Visual Studio. This tool is available in your Window programs and can be found using the default Windows search.
2. Ensure your prompt has access to the following tools by executing them once: sn ildasm and ilasm
3. Navigate to the folder where your Cool.Library.dll is located
4. sn –k Cool.Library.snk to create a new key pair
5. ildasm Cool.Library.dll /out:Cool.Library.il to disassemble the library
6. move Cool.Library.dll Cool.Library.unsigned.dll to keep the original library as a back-up
7. ilasm Cool.Library.il /dll /resource=Cool.Library.res /key=Cool.Library.snk to reassemble the library with a strong name
8. powershell -command "& {[System.Reflection.AssemblyName]::GetAssemblyName($args).FullName} Cool.Library.dll" to get the assembly fully qualified name. You will need this bit if you have to reference the DLL in external configuration files like web.config or app.config.

Heilner

Answer 8

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.

Choirboy

I found one issue with StrongNamer that the re-signing solutions don't seem to suffer from: datatips in the debugger don't work in any method where the library is used. Or at least they didn't in the one project I've used this in. I went back and did the full re-signing (which is PITA since it's a NuGet project that'll probably get updated at some point), and debugging now works as it should. – Devries

@Devries I have not encountered this issue, but I use JetBrains Rider – Journalese

StrongNamer no longer works with .net 4.7 and newer frameworks, it stopped working at 4.6.1 – Demitria

Answer 9

I was running into this with a ServiceStack DLL file I had installed with NuGet. Turns out there was another set of DLL files available that were labeled signed. Not going to be the answer for everyone, but you may just need to check for an existing signed version of your assembly.

Cricket

Answer 10

I had this issue for an app that was strongly named then had to change it in order to reference a non-strongly named assembly, so I unchecked 'Sign the assembly' in the project properties Signing section but it still complained. I figured it had to be an artifact somewhere causing the problem since I did everything else correctly and it was just that. I found and removed the line: [assembly: AssemblyKeyFile("yourkeyfilename.snk")] from its assemblyInfo.cs file. Then no build complaints after that.

Fabrienne

Thank you! Because of your answer I recheck it for my issue (ClosedXML) and found ClosedXML.Signed nuget package as well. – Florid

Answer 11

Use ilmerge. ilmerge is from Microsoft, but it is not shipped with Visual Studio or the SDKs. You can download it from here though. There is also a GitHub repository. You can also install from NuGet:

PM> Install-Package ilmerge

To use:

ilmerge assembly.dll /keyfile:key.snk /out:assembly.dll /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /ndebug

If needed, you can generate your own keyfile using sn (from Visual Studio):

sn -k key.snk

Beeeater

I had the issue with WireMock.Net, finally got it working, but took me a little time to figure out the PowerShell commands. Particularly the whole bunch of /lib arguments to finally get ILMerge to sign the assembly. – Kindness

1> Register-PackageSource -ProviderName NuGet -Name NuGet -Location http://www.nuget.org/api/v2 – Kindness

2> Install-Package -Name ILMerge – Kindness

3> $env:path += ';C:\Program Files\PackageManagement\NuGet\Packages\ilmerge.2.14.1208\tools' – Kindness

4> ILMerge.exe .\packages\WireMock.Net.1.0.4.2\lib\net452\WireMock.Net.dll /keyfile:key.snk /out:WireMock.Net.dll /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /ndebug /lib:.\packages\Newtonsoft.Json.10.0.3\lib\net45\ /lib:.\packages\Handlebars.Net.1.9.0\lib\net40 /lib:.\packages\SimMetrics.Net.1.0.4\lib\net45 /lib:.\packages\Microsoft.Owin.2.0.2\lib\net45 /lib:.\packages\Owin.1.0\lib\net40 /lib:.\packages\Microsoft.Owin.Hosting.2.0.2\lib\net45 /lib:.\packages\MimeKitLite.2.0.1\lib\net45 /lib:.\packages\XPath2.1.0.5.1\lib\net40 /lib:.\packages\RestEase.1.4.4\lib\net45 – Kindness

Answer 12

I added NuGet package 'StrongNamer' and my problem solved.

Giaimo

This was a gift - thank you so much since I was struggling to find in a project of so many references. – Renaissance

Answer 13

For me my issue was that I had two of the same NuGet packages installed with different versions.

Glauconite

Answer 14

Removing the "Sign the assembly" check mark under the "Signing" tab works as @Michal Stefanow said.

Add here is the simplest way to sign your own files and/or other people's files. You just need to add this line under the "Post-build event command line":

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)\YourPfxFileNameHere.pfx" /p YourPfxFilePasswordHere /d "Your software title here" /du http://www.yourWebsiteHere.com /t http://timestamp.verisign.com/scripts/timstamp.dll /v "$(BaseOutputPath)$(TargetFileName)"

You can sign other people's files or your own files and as many as you want.

Benelux

This is a different kind of signing. What the OP is asking is how to sign a .NET assembly with a strong name. You're showing how to sign an executable with a code signing certificate. Different things. – Manslayer

Answer 15

Situation: You had project A,B,C,D in solution X,Y

Project A, B, C in X Project A, C, D in Y

I need use project C in project A, but later i dont use. In bin Debug project A had C.dll.

If I compile solution X, all good ( in this solution i delete reference A -> C. ), but in solution Y I get this problem.

Solution is delete C.dll in project A bin Debug

Peers

Answer 16

First make sure all NuGet packages are at the same version across all projects in your solution. E.g., you don’t want one project to reference NLog 4.0.0.0 and another project to reference NLog 4.1.0.0. Then try reinstalling NuGet packages with

Update-Package -reinstall

I had three third-party assemblies that were referenced by my assembly A and only two were included in References by my assembly B which also referenced A.

The missing reference to the third-party assembly was added by the update package command, and the error went away.

Coe