Assembly has a strong name, but I"m getting the error that says a strong name is needed

11

I am trying to load a third party COM dll into my application. Everything builds fine but when I run the application I keep getting this message from my application:

Could not load file or assembly '"assembly", Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044).

When I do a sn -vf "assembly" it says the assembly is valid. Has anyone seen this type of behavior before?

.net
com
strongname
asked on Stack Overflow Aug 21, 2015 by Mykal73 • edited May 30, 2018 by nvoigt

4 Answers

11

The assembly you are trying to load does not have a strong name. This can be seen by your message, it says PublicKeyToken=null. If it had a strong name, it would have a public key token.

If you have given it a strong name after you compiled or referenced it, try to reference it again in your project. Maybe your project has still the old reference and is trying to load an unsigned version.

answered on Stack Overflow Aug 21, 2015 by nvoigt
2

I have seen the behavior before when working with the Mongo CSharp Driver. From Version 1.10.0 and up they stopped providing strongly named assemblies, so you had to sign them yourself.

When I signed the 3 dll's provided; MongoDB.Bson, MongoDB.Driver, and MongoDB.Driver.Core, I neglected the built in dependency structure of those assemblies. MongoDB.Driver was dependent on MongoDB.Driver.Core which was dependent on MongoDB.Bson. This meant although my code was referencing the signed assemblies the pre-compiled assemblies were referencing the signed assemblies they were dependent on.

In general you'll observe this behaviour when you have a dependency tree such as this

Assembly1 -------> Assembly2
   |                   |
   |---> Assembly3 <---|

Where both assemblies 1 & 2 are dependent on assembly 3 but assembly 1 is also dependent on assembly 2. Its one step short of a circular dependency which makes it very rare.

I discuss the process and SDK tools available for signing a 3rd party DLL and resolving this issue in part 4 of the 5 part series. .NetFU also had a good article on the process but their page has since been removed.

answered on Stack Overflow Aug 17, 2016 by TheDude
0

If you have different projects, they all need to be signed. You can't sign one with a certificate and not sign the other ones.

answered on Stack Overflow Oct 24, 2020 by (unknown user)
-1

I had this issue with a project using the new csproj format, form the top of the file:

<Project Sdk="Microsoft.NET.Sdk">

Along with the PackageReference to simply the name of package. So, no local packages folder. Looking in the properties for package within Visual Studio, I could see a full path to the DLL in the .nuget file cache:

%USERPROFILE%\.nuget\packages

I'm not sure of how the linking / referencing works, but even the having the application and signed version of package in the same directory, still would not work. The application was referencing information from the DLL in the nuget cache.

So my workaround was the replace the DLL in the nuget cache with the signed version of the DLL.

answered on Stack Overflow May 21, 2019 by Jahmic

User contributions licensed under CC BY-SA 3.0