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?
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.
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.
来源：https://stackoverflow.com/questions/11656520/signing-binaries-of-open-source-projects