There are two projects:
a.csproj -> .NET 4.6.1
b.csproj -> .NET Standard 1.3
There is one class in each of the projects:
a.csproj has class A (.NET 4.6.1)
b.csproj has class B (.NET Standard 1.3)
case 1: A calls a method from B where the method returns something, lets say string. Everything works fine.
case 2: A calls a method from B where the method lets say prints to a console. in A you get an exception "Could not load file or assembly System.Console". To fix this, you add a reference to "NETStandard.Library" in a.csproj project. After this everything works fine.
case 3: A calls a method from B where the method uses some dll lets say MysqlData or HtmlAgility pack or w/e installed from a nuget package. In A you get an exception "Could not load file or assembly '". To fix this you install the same package in a.csproj project but depending on package you may get inner exception "Strong name validation failed" inner exception.
How to deal with case 3?
You would have to carefully analyze the inner exception to see which assembly triggers it.
.NET Core tooling based projects such as .NET Standard Class Library projects introduces the concept of "public signing" (which is similar to delay signing). So unless a project is configured as
Then the compiled assembly can only be consumed by .NET Core apps, as they accept public signed assemblies.
A proper project should use
So that its output can be consumed by .NET Framework projects.
Locate the culprit assembly which was not signed properly, and you should report to its developers. Once they fix the signing issue and ship a new version of NuGet package, your issue can be resolved.
If you just want to workaround it, you probably can follow delay signing practice to suppress strong name validation temporarily on your machines,
https://learn.microsoft.com/en-us/dotnet/framework/app-domains/delay-sign-assembly