Strong name library so it can be used on .NET Framework from strong named assemblies about ilpack HOT 6 CLOSED

#156 has been merged. Thanks!

from ilpack.

@AArnott Thanks a lot for your feedback. Unfortunately, supporting the .NET Framework is not part of our ambition for this library, as it's just a replacement for something is actually available in .NET Framework. My own gut-feeling is that strong-naming .NET assemblies is a some extra friction for not much added value.

If you feel strongly about it, it could be done though, although, but we should start the bugs like #117 that (probably) prevent you from using ILPack in the first place.

from ilpack.

My own gut-feeling is that strong-naming .NET assemblies is a some extra friction for not much added value.

Strong naming is frictionless on .NET Core, and generally a good thing on .NET Framework too. See https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named for more info.

supporting the .NET Framework is not part of our ambition for this library

Then why target .NET Standard in your library? Why not just target .NET Core and make it clear that folks who want to target .NET Framework shouldn't use it?
FWIW though, I own many libraries, all of which run on both runtimes and a few of which need to use Ref.Emit. I am looking for a way that works on either runtime to write out the dll to disk.

but we should start the bugs like #117 that (probably) prevent you from using ILPack in the first place.

Agreed. I am not sold on using this unless this and perhaps other issues I see filed against this project are resolved to the point where I'm convinced that I can rely on this.

from ilpack.

Then why target .NET Standard in your library? Why not just target .NET Core and make it clear that folks who want to target .NET Framework shouldn't use it?

Well, the .NET Standard support has been brought by a community contributor. I did not want to reject the PR on the sole basis of not supporting .NET Standard. However the in the first paragraph of the ReadMe.md, it's .NET Core that is mentioned. Lokad does not have the resource to support the .NET Framework, but if some people wants to contribute in this area, I will try not to be in the way.

from ilpack.

@vermorel I'll try to summarize information about assembly stong naming here and will include it into a separate .md file if needed in the scope of the related PR.

1. The strong naming provides an identity for assembly, allows to use in binding redirection, loading different versions side-by-side, using them in a 'signed' context, and placing them into the GAC.
2. The strong name private/public key pair (a .snk file) is a source of this identity. We are unable to use different .snk files for the development and release process because in this case, we will have different identities.
3. It will prevent users from using a modified version of assembly for debugging/testing without full application re-compilation.
4. There is an option of "public sign" (or "OSS sign") that allows committing only the public key into the repo and marking output as fully signed just by adding this public key. In this case, we can use a proper private/public pair for CI/CD build but you have to manage this "full" .snk file somehow outside of the Git repo.

There are some useful links related to the previous list:

• Command-line options for the SN tool - how to create a new .snk file and export public key as a separate file
• Open-source library guidance from Microsoft - Strong naming - see info about managing the .snk file
• Public sign project file option for the dotnet SDK/MSBuild (can be used conditionally)
• Some ideas for using the non-committed .snk file in CI/CD pipeline.

from ilpack.

Strong naming is not about security:

A strong name signature does not guarantee the trustworthiness of the person who signed the assembly or indicate whether that person was a legitimate owner of the key; it indicates only that the owner of the key signed the assembly. Therefore, we do not recommend using a strong name signature as a security validator for trusting third-party code. Microsoft Authenticode is the recommended way to authenticate code.

Hiding the private key just adds complexity to the process and violates the spirit of OSS, since no one can actually reproduce their own build of the binary and expect it to work like the original. I suggest just checking in the full snk file, which is what I do in all my repos, OSS or not.

from ilpack.