Что рекомендуемый путь состоит в том, чтобы управлять парой ключей строгого имени для проекта с открытым исходным кодом?
Все, кто говорит, что управление исходным кодом для 1-2 разработчиков - необходимость, полностью, абсолютно правильные. Доверяйте нам:-)
Назад в колледже, у меня был преподаватель, который заставил нас использовать управление исходным кодом. Все мы ударили и кричали, потому что CVS казался слишком сложным и излишеством, на которое походят, для студенческих проектов. В конечном счете все мы пришли, и даже для простых проектов с тех пор я поместил их всех в управление исходным кодом. Я продолжил это по сей день и сохранил меня со многих часов разочарования.
2 ответа
] Решение Sharptooth хорошо работает, если единственные ссылки на сборки в коде - это те, которые закодированы в файлах проекта. Если ваш проект ссылается на другие сборки через InternalsVisibleToAttribute или другие средства, где требуется строка строгого имени, то создание исходных файлов репозитория с временным ключом невозможно. Это приведет к изменению ссылок на открытый ключ, которые присутствуют в строках строгого имени, и нарушит код.
Так обстоит дело в моем приложении, поэтому мне нужно было принять другой подход.
По сути, я создал копию файлов sln и csproj в отдельной иерархии папок и изменил файлы csproj следующим образом.
- Преобразовал все ссылки файлов на ссылки, указывающие на исходные источники.
- Каждый файл AssemblyInfo.cs скопирован и изменен, чтобы он содержал использование
InternalsVisibleToAttributeсо строгим именем. - Изменено каждый
csprojфайл, так что ссылка на файлsnkявляется относительным путем (устраняет необходимость копировать файлsnkв каждый проект)
Сначала я сделал все это вручную, но потом понял что это можно автоматизировать простым способом. Первый и третий этапы могут быть реализованы с помощью XSLT, а второй этап может быть реализован с помощью функции поиска / замены регулярного выражения.
Вы не должны распространять пару ключей. Строгое имя предназначено для проверки того, что новая версия сборки исходит от того же издателя.
Если другой разработчик хочет разветвить ваш проект, он сгенерирует свою собственную пару ключей, и это будет эффективно показывать, что его версия не от вас, так что другие сборки которые зависят от вашего, больше не будут загружаться, пока они не будут перекомпилированы. Это не всегда удобно, но защищает вас от того, что кто-то выпустит вредоносную версию сборки и незаметно ее распространит.