Каков рекомендуемый способ управления пары ключевых слов с сильным именем для проекта с открытым исходным кодом?

Question

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

Как я могу подписать полученные двоичные файлы моей сборки и не должен распространять файл ключа-ключа snk? Если я использую Visual Studio для подписи сборок, каждый файл проекта теперь нуждается в копировании пары ключей для сборки. Мне не удобно распространять ключ-пару, даже если она защищена паролем.

Edit:

Другой нюанс в том, что некоторые узлы в проекте доступе к другу через грант InternalsVisibleToAttribute и построить те друг через ссылку проекта. Следовательно, такие сборки должны использовать сильное имя при обращении к подписанной сборке. Однако, если пара ключей не распределена, то как конечные пользователи могут создавать источники и поддерживать отношения проекта? Если используется временный файл пары ключей, не изменится ли токен открытого ключа подписанных сборок, нарушив ссылки InternalsVisibleToAttribute?

Answer 1

Sharptooth's solution хорошо работает, если единственными ссылками на сборку в коде являются те, которые закодированы в файлах проекта. Если ваш проект ссылается на другие сборки через InternalsVisibleToAttribute или другие средства, где требуется строка с сильным именем, тогда невозможно создать источники хранилища с временным ключом. Это приведет к изменению ссылок на публичные ключи, которые присутствуют в строках с сильным именем и сломают код.

Это касается моего приложения, поэтому мне необходимо принять другой подход.

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

• Превратил все ссылки на ссылки, ссылаясь на исходные источники.
• Скопировал и модифицировал каждый файл AssemblyInfo.cs, чтобы использовать использование InternalsVisibleToAttribute с сильным именем.
• Modified каждый csproj файла, так что ссылка на файл snk относительный путь (устраняет необходимость копирования файла snk к каждому проекту)

я первый сделал все это вручную, но потом понял, что это может быть автоматизированным в простой форме. Первый и третий шаги могут быть реализованы с помощью XSLT, где, поскольку второй этап может быть реализован с помощью функции поиска/замены регулярного выражения.

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

Источники в репозитории не строят сборки с простыми именами, это нормально, поскольку я не хочу налагать какие-либо ограничения или процессы сборки для конечных пользователей.

Answer 2

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

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