Рекомендации по подписке сборок с несколькими проектами и разработчиками

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

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

Мои мысли до сих пор:

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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