Signed Version in NuGet

[MarkLFT]

This is a very useful library. But I think it would be more useful if the library is signed, as currently I cannot use NuGet to get this library.

[gustavofrizzo]

Hey!
Are you talking about strong names, right?

I was reading about it:

• https://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/
• Signed Octokit Releases - Yea or Nay? octokit/octokit.net#405
• https://twitter.com/eric_sink/status/623939641687830529
• Sign LibGit2Sharp.dll by a strong name libgit2/libgit2sharp#212

Looks like it may not be worth signing the assemblies. But if you really need you can fork the project and create your own signed assembly. It looks pretty straightforward.

[MarkLFT]

Many thanks for your reply, and I agree strong names can be a pain. Unfortunately they are still a necessity. We have a very large solution, that contains around one hundred projects, all inter-dependent, and the problem we have is several of our core programs force us to use signing, this in turn means we can only use signed libraries. We are well aware of branching, and self-signing, but this comes with even bigger perils. Until recently we used a library in such a way. The problem is, sometimes the developers forget this library has a self-signed version, and pull an upgraded version from nuget. As the compiler does not pick up problem, it is not until runtime we find out. This has caused us headaches a few times, so we have basically had to stop using any libraries that require self-signing. As the top story to mention stated, it takes 2 seconds to sign a library, and once signed, can be used by anyone, you cannot say the same about the unsigned version. The issue of versioning, again, just rely on the nuget versioning, and all works fine. I understand if you don’t want to sign it, I have had the same discussion with a few other developers, it just means I, and many other developers will be easily be able to use your library. Best regards Mark From: Gustavo Frizzo [mailto:notifications@github.com] Sent: 16 December 2017 15:14 To: gustavofrizzo/CreditCardValidator <CreditCardValidator@noreply.github.com> Cc: Mark Townsend <Mark@LittleFishCom.net>; Author <author@noreply.github.com> Subject: Re: [gustavofrizzo/CreditCardValidator] Signed Version in NuGet (#9) Hey! Are you talking about strong names, right? I was reading about it: * https://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/ * octokit/octokit.net#405<octokit/octokit.net#405> * https://twitter.com/eric_sink/status/623939641687830529 * libgit2/libgit2sharp#212<libgit2/libgit2sharp#212> Looks like it may not be worth signing the assemblies. But if you really need you can fork the project and create your own signed assembly. It looks pretty straightforward. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#9 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AE5hO55bzAxLcH3RqyN5MoBZbRZAU7h9ks5tA23QgaJpZM4Q_7KS>.

…

-- This email was Malware checked by UTM 9. http://www.sophos.com

[gustavofrizzo]

Hey,
I see. I will take a better look at that.
So, the best solution would be to freeze the dll version (2.0.0 would work, right?) and then update only the nuget version?

If so, this process seems to be fairly simple and I guess it won't affect projects that already use it.