Этот вопрос является продолжением следующего:
- Следует ли подписывать каждый проект отдельным ключом строгого имени (.snk)?
- snk и сертификат подписи кода
- Есть ли причина для отправки файла .snk с исходными кодами проекта?
- https://docs.microsoft.com/en-us/dotnet/standard/assembly/enhanced-strong-naming
Я смотрю на Strong Naming для настраиваемой сборки вместе с кодом, подписывающим ее, и читал различные сообщения SO (см. Выше) и MSDN. Я понимаю следующее:
- Строгое именование сборки без пароля создает файл SNK и идентифицирует только издателя сборки, чтобы ее можно было развернуть в GAC и смягчить так называемый
DLL Hell, вызванный сборками с одинаковыми именами от разных издателей . - Строгое именование сборки паролем добавляет к сборке подпись кода и создает файл PFX вместо файла SNK. Это одновременно идентифицирует издателя и подтверждает, что код не был изменен. Примечание. Этот файл может быть создан и, следовательно, импортирован доверенным центром сертификации, таким как Verisign и Digicert, или это может быть самозаверяющий сертификат, созданный внутри организации. Самостоятельное создание PFX - это тот же шаг, что и создание сборки со строгим именем, но вы просто добавляете к ней пароль.
- Расширенное строгое именование кажется мне загадкой. Он включает в себя создание файла SNK со строгим именем (т. Е. Без пароля) и последующее извлечение из него закрытого ключа. Похоже, это только для разрешения перехода с устаревших алгоритмов хеширования.
Я понимаю, что 2 является логическим продолжением 1. Правильно ли я понял выше? Но в чем разница между 2 и 3 выше? Имеет ли 3 какое-либо преимущество перед 1 или это просто способ разрешить миграцию только между алгоритмами? Другими словами, я полагаю, что 2 и 3 существуют по разным причинам; что это за причина / реализация?
