Подписание двоичных файлов проектов с открытым исходным кодом

Я попытался использовать ServiceStack в моем текущем проекте, но обнаружил, что выпущенные двоичные файлы не были сильными, поэтому я не мог использовать его из коробки. Когда вы спрашиваете GitHub "почему", я получил следующий ответ:

он вирусно токсичен и препятствует связыванию, модернизации, развитию, развертывание и т.д.

Мифц был очень лаконичен, поэтому я не хотел больше беспокоить его и спрашивать здесь. Я использую много проектов с открытым исходным кодом .NET, таких как AutoMapper, NUnit, Moq, log4net, Ninject и т.д., И их выпуски имеют сильные имена. Нашел аналогичный вопрос здесь, на SO, но это мне не помогает. Это обычная практика в OSS? Почему бы не выпустить как подписанные, так и неподписанные двоичные файлы?

Ответ 1

Здесь существующее обсуждение причин, почему Strong Naming - плохая идея для проектов с открытым исходным кодом:

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

Вот история кошмара от его использования:

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

Я лично был в двух командах, которые пострадали от 2-х поколений Log4Net, которые пытались использовать сборки, ссылающиеся на 2 разных сильно названных версии Log4Net в одном проекте - тратя много времени и усилий, пытаясь сделать эту работу это не забава, и мы не планируем подвергать себя или не доверять всем нашим пользователям.

Пользователи, которым требуется сильная версия, могут свободно подписывать свой собственный клон /fork публичных репозиториев ServiceStack.

Если есть спрос на него, мы рассмотрим возможность сохранить наши собственные официальные коммерческие версии наших библиотек.

Ответ 2

Я думаю, что это касается разработчиков. Плюсы понятны - каждый может принять сборку с сильным именем и использовать ее в любой среде. В этом конкретном случае я имею в виду от подписанной или неподписанной сборки. Минусы -?

Я думаю, что должно быть своеобразным джентльменским правилом для подписи двоичных файлов.

Джон Скит ответил на аналогичный question, и его мнение довольно маловероятно.