Лучшие практики для подписания сборок с несколькими проектами и разработчиками

Question

Я ищу рекомендации и рекомендации по применению подписанных сборок в организации с более чем 30 разработчиками, более чем 20 решениями и более чем 60 проектами. Мы используем Visual Studio Team System 2008 и TFS.

Хотя создание ключа и подписание сборки - это очень простая и понятная процедура, меня интересует, как мы справляемся с этим наилучшим образом.

Пока мои мысли:

• Каждое решение, которое обычно содержит от 3 до 20 проектов, будет иметь один файл ключа .pfx, помещенный в корневую папку решения.
• Каждое решение будет иметь уникальный надежный пароль для ключа.

Будем ли мы сталкиваться с какими-либо проблемами при таком подходе?

Некоторые другие идеи:

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

Любой вклад, хороший / плохой опыт и рекомендации приветствуются. :)

Answer 1

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

Примечание. Чтобы использовать файл с одним ключом, проще всего было добавить файл в качестве ссылки на каждый проект.

Единственный недостаток, который я вижу, заключается в том, что наличие файла ключа, доступного вашим разработчикам, означает, что он не настолько приватен, как должно быть. В идеале, как можно меньше людей (например, только процесс сборки) должны иметь доступ / знать пароль.

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

Answer 2

В настоящее время мы используем один и тот же сильный ключ (.SNK) для каждого проекта в нашем решении. В зависимости от вашего проекта, как вы управляете различными ключами для каждого проекта.

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

Для этого вы должны ограничить свой контроль исходного кода и посмотреть на использование сервера сборки и т. Д., Если вы не доверяете / не хотите, чтобы разработчики создавали код.

Answer 3

Вы также можете хранить ключ строгого имени в папке на корневом уровне, на том же уровне, что и все папки проекта. Когда вы выбираете этот файл в свойствах проекта -> вкладка подписи, файл ключа копируется в папку проекта. Удалить этот файл Откройте файл .csproj в блокноте. Ищите следующий тег mykey.snk Вручную отредактируйте путь к файлу ключа, убедитесь, что вы указали относительный путь из папки проекта. Сохраните файл. Теперь откройте свойства проекта в visual studio. Вы можете видеть путь, обновленный, чтобы указать на правильное местоположение.