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?
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.
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.
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.
