15

I tried to use ServiceStack in my current project but found the binaries released were not strong named so i couldn't use it out of the box. When asking on GitHub "why" I got the following answer:

it's virally toxic and hinders binding, upgrading, development, deployment, etc.

mythz was very laconic so I didn't want to bother him more and asking here. I use a lot of open-source .NET projects like AutoMapper, NUnit, Moq, log4net, Ninject, etc. and their releases are all strong named. Found similar question here, on SO, but it doesn't help me. Is it normal practice in OSS? Why not release both signed and unsigned binaries?

Community
  • 1
  • 1
UserControl
  • 14,766
  • 20
  • 100
  • 187

2 Answers2

6

Here's an existing discussion on reasons why Strong Naming is a bad idea for Open Source projects:

https://groups.google.com/forum/?fromgroups#!topic/getglimpse-dev/pXXazMOOdjE

Here is a nightmare story from using it:

http://haacked.com/archive/2012/02/16/changing-a-strong-name-is-a-major-breaking-change.aspx

I've personally been in 2 teams that have suffered through 2 generations of Log4Net that have tried to use assemblies referencing 2 different strong-named versions of Log4Net in the same project - Wasting lots of time and effort trying to make this work is not fun, nor is it something we plan to subject ourselves or mandate all our users too.

Users that want a strong-named version are free to sign their own clone/fork of the public ServiceStack repos.

If there is demand for it, we will consider maintaining our own "Officially Singed" commercial versions of our libraries.

mythz
  • 141,670
  • 29
  • 246
  • 390
  • 2
    Thanks for the links, quite interesting but I have to note that the guys mix signing and versioning - different things! Although in .NET world signature is part of strong name one does not have to change version when releasing new build (log4net version scenario; instead they could use file versioning and kept IL version same). I see no problems releasing unsigned binaries, signed with same IL version and signed with incremented IL version. There are options for all to be happy so here is my +1 when you reconsider maintaining "Officially Signed" binaries. – UserControl Jul 26 '12 at 06:02
  • 2
    You can't 'authenicode' sign assemblies which have non-strong name dependencies. Personally, it's a nightmare *not* having easy access to strong named assemblies and massively hinders deployment. – Robin Oct 11 '13 at 13:50
  • 3
    I realize I'm a bit late to the party here, but I really don't see the problem with signing the assemblies. In what way is signing a problem if you keep using the same key? Don't assembly redirects solve the versioning problem? – dabide Oct 24 '13 at 21:34
  • Note that the "Nightmare story" is all about *changing* a strong name key pair without increasing the major or minor version number, thereby causing a versioning problem with NuGet which by default takes the latest build of the same major.minor version as far as I understood it... – Lucero Feb 26 '15 at 13:42
  • I'm also late to the party, but I don't see any motivation **for** strong-naming assemblies, especially open-source ones. They're only useful when installing to the GAC, so the simple solution is to never use the GAC. I've never had a problem with this strategy, while I've had endless problems with strong-named files. I wish everyone would stop signing things. – Miral Jul 17 '15 at 06:13
5

I think it's up to developers. Pros are clear - anyone can take assembly with strong name and use it in any environment. In that particular case I mean from signed or unsigned assembly. Cons - ?

I think it should be a kinda gentleman rule to sign binaries.

Jon Skeet answered on similar question and his opinion is quite undestandable.

Community
  • 1
  • 1
Sergio Rykov
  • 4,176
  • 25
  • 23