Sign NuGET build artifacts

[vmedvedovskiy]

Could you please sign binaries, produced for NuGET?
This will allow for your libraries to be referenced from strong named assemblies (signed).

[nlkl]

Sounds like a good idea - I will just need to investigate the consequences fully. Your thoughts on this are welcome as well, of course.

Refs (for my own sake):
https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md
http://james.newtonking.com/archive/2012/04/04/json-net-strong-naming-and-assembly-version-numbers
JamesNK/Newtonsoft.Json#615
http://nickberardi.com/json-net-strong-naming-and-nuget-woes/
http://www.heartysoft.com/ashic/blog/2015/9/dont-strong-name-existing-nuget-packages
octokit/octokit.net#405

[agehrke]

You can use Strong Name Signer to automatically sign assemblies pulled in via NuGet.

https://github.com/brutaldev/StrongNameSigner

[nlkl]

I have been considering the problem, and all in all it seems that strong naming the assemblies will create more problems than benefit.

Having had my own fair share of fights with binding redirection from strong named assemblies such as Newtonsoft.Json, I am quite hesitant to strong name Optional. Further, it seems that the community as a whole are moving away from strong naming, particularly when distributed through Nuget.

Certainly, strong naming causes much more severe problems for popular and often referenced packages such as Newtonsoft.Json than it would in this case, but Optional was always meant to be a lightweight dependency, and including Optional in a project should certainly be as frictionless as possible. Juggling with binding redirects hardly seems in line with this idea.

Unfortunately, this introduces some real inconvenience for projects that are using strong names. However, once you are going down the path of strong naming your assemblies, I suspect this is the smallest of your inconveniences anyway. The tool that @agehrke mentions seems to be a valid and localized solution (another alternative could be https://github.com/dsplaisted/strongnamer), that has the benefit of being independent on whether or not all relevant package owners strong name their assemblies (even if we strong name Optional, your other package dependencies might still not be).

Now, it does seem that .NET Core and friends are starting to ease the pain of managing binding redirects, and I might just reconsider at a later point. Also, there are certain tricks to ease the pain, such as only incrementing assembly versions on major releases etc., but this has its own pitfalls too.

Edit:

Freezing the assembly version and only incrementing assembly file version and package versions might actually be a viable solution - and one that is used by several existing Nuget packages. I will look a bit more into this - if there are no downsides, this might be the way to go.

[DerPeit]

I don't see the problems you're talking about. I have never had any issues with assembly redirects as long as the snk file used to sign the assemblies does not change. @nlkl which sources do you rely on that raise your concerns?

A different approach would be to create two different packages like for example Flurl does:

https://www.nuget.org/packages/Flurl/
https://www.nuget.org/packages/Flurl.Signed/

[jakubsuchybio]

Completely agree with @DerPeit why not making secondary Nuget with .Signed? I am trying to use your Nuger in my new VS Extension, but can't because there you can reference only signed references.
Please consider it @nlkl Thx

[lsolano]

Same issue as @jakubsuchybio with a VSTO add-in. We do sing your assembly and upload a private package to our Nuget feed (Nexus); works but add extra steps with every new version of your package.

[nlkl]

Hi @jakubsuchybio and @lsolano

Although I am not completely against the idea, I recommend that you try out a solution like https://github.com/dsplaisted/strongnamer or similar first - any concrete experiences with this approach?

/ Nils

[Galad]

Hello,
We also have strong named assemblies and we currently use https://github.com/brutaldev/StrongNameSigner. We consider moving our projects to PackageReference but unfortunately, StrongNameSigner is not compatible with it at this time.
Recently Microsoft published some documentation about signing open sourced libraries.
I suggest @nlkl you take a look at it, maybe it will help you making a decision.

[MitchBodmer]

Hey @nlkl I'd like offer another vote in favor of signing.

Currently the guidance is in favor of signing publicly published .NET libraries. Even some of the most vocal critics of signing have changed their tune.

Personally, I end up writing libraries that are used by a variety of projects, and signing is the best way I've found to support everyone. The pain from binding redirects is mostly gone now with .NET core.

In my opinion the benefits far outweigh the costs. Every time I'm working on a project that must be signed and see an excellent use for Optional, I get sad.

[nlkl]

Hi @MitchBodmer

I agree and my opinion on this has changed as well. Let us strive to sign the assemblies from v5.

Thanks for reminding me of this!

/ Nils