расположение файла .snk и управление им

Question

В настоящее время я настраиваю свои библиотеки .net для подписи строго типизированным ключом. Я использую файл .snk, чтобы подписать мои DLL на основе решения. Так что для каждого решения у него есть свой собственный файл .snk. Это правильная практика? Например, у меня есть библиотека классов, которая выводит несколько разных dll-файлов из каждого проекта решения, каждый из которых подписан ключом .snk.

Мой вопрос касается хранения ключа в системе контроля версий. Как я разветвляю свой код для каждого выпуска. Если ключ:

A. Существовать вне ветвей и не быть разветвленными - обеспечивая одинаковый ключ для каждой ветви Б. Существовать в филиале, но быть одинаковым для каждой ветви C. Существуют в филиале и меняются для каждого филиала D. Другое (просьба указать)

Предложения, пожалуйста?

Также рекомендуется подписывать DLL, поместив в файл SolutionInfo следующую информацию или есть альтернатива?

[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")]

Answer 1

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

Другой - для всех остальных, вы просто подписываете сборку, чтобы передать ее в GAC илипотому что вы отправляете его второму лицу, которое может хочет поместить его в GAC.Фактический ключ, который вы используете, не имеет значения, и вы не должны помещать его в большое хранилище.Просто используйте Project + Properties, вкладку Signing.Сгенерируйте ключ и зарегистрируйте его вместе с проектом.

Answer 2

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

Вариант использования: мы меняем наш ключ подписи сборки между v1.0 и v2.0. Вы все еще хотите иметь возможность поддерживать текущий код в транке, одновременно разрабатывая правильный ключ в вашей ветви (ветках).

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

Это предотвращает распространение вашего закрытого ключа, который должен храниться защищенным на сервере сборки (скорее всего, в диспетчере ключей Windows) и использоваться во время сборок "выпуска" для полной подписи сборок. Если у вас нет сервера сборки, рекомендуется, чтобы 1 или 2 человека доверяли закрытый ключ, после чего они могут подписать сборки с помощью sn.exe после сборки. Простой сценарий оболочки или командный файл могут автоматизировать этот процесс.

Наконец, и только если вы решите отложить подпись, вам нужно будет добавить запись в список проверки сборки .NET (sn.exe -Vr *,<publicKeyToken>) на всех рабочих станциях разработчика, которые будут запускать / отлаживать отложенные подписанные сборки. В зависимости от цели платформы вам нужно будет запустить ее как в 32-, так и в 64-битной версиях командной строки VS.

Надеюсь, это поможет.