search

accord-net / framework

Machine learning, computer vision, statistics and general scientific computing for .NET
http://accord-framework.net
GNU Lesser General Public License v2.1
4.48k stars 1.99k forks source link

NetStandard assembly does not have strong name #1338

Open AndMu opened 6 years ago

AndMu commented 6 years ago

What would you like to submit? (put an 'x' inside the bracket that applies)

Issue description

I have library compiled as NetStandard. It references Accord.MachineLearning. If I use library in a .Net 462 project, I am getting the error:

LOG: Assembly Name is: Accord.MachineLearning, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7 WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN

As new project copies with a strong name, implementing 462. I think signing netstandard assembly, should solve this issue.

cesarsouza commented 6 years ago

Hi @AndMu!

Thanks for opening the issue! However, strong signing assemblies for .NET Standard is now discouraged, e.g. please see

If you are using the library in a net462 project, I would recommend using the framework assemblies that have also specifically been built for net462, as they should have been strongly signed.

Hope it helps, Cesar

AndMu commented 6 years ago

I do agree with .Net Standard recommendation. But I think you do not understand where the problem is.

Mixing signed and no signed assemblies in same nuget does not work. To be fair I am not sure why to even include anything else except .Net Standard version. Isn’t a purpose of .net standard to be compatible with different frameworks? Including all other .NET versions is kind of going against the idea?

sahin-ozsoy commented 6 years ago

I am having exactly the same issue. Tried several workarounds with no success.

grondinjc commented 5 years ago

@cesarsouza It appears that one of your sources changed entirely his mind : https://www.pedrolamas.com/2018/09/11/start-strong-naming-your-assemblies/

ltrzesniewski commented 5 years ago

Agreed. I just got the same error. Either all assembles should be signed, or they all should be unsigned. The 3.8.0 package is broken because of this, and I need to multi-target my library instead of going for netstandard2.0. 😞

yaakov-h commented 5 years ago

@cesarsouza My company is encountering the same issues outlined here.

Your sources are also no longer applicable.

In the CoreFX document linked above, Microsoft now state:

Because of the viral nature of strong-naming, it is recommended that publicly published .NET libraries are strong-named.

Pedro Lamas has changed his mind, as linked at the top of that blog post.

And under Microsoft's guidance about strong naming, they state:

You should strong name your open-source .NET libraries. Strong naming an assembly ensures the most people can use it, and strict assembly loading only affects the .NET Framework.

Can we get Accord updated to follow this guidance?

Ozzah commented 5 years ago

I'm having exactly the same issue. I'm trying to use Accord in a .NET Standard library project, and I can't sign my library because Accord isn't signed. Like the others here, I've hunted for a solution for quite some time, but in the end I've had to abandon Accord until this is resolved.

jmecosta commented 4 years ago

@cesarsouza its 2020, everyone is providing identity for open source assemblies please sign yours also!