В некотором коде C #, который я перенял (в Visual Studio 2005), я заметил, что все сборки подписаны одним и тем же .snkфайлом.
Ответы:
Почему предыдущий автор подписал сборки таким образом?
Не знаю, может быть, он хотел, чтобы все его сборки были подписаны одним и тем же ключом.
Нужно ли подписывать собрания и что было бы неправильно, если бы оно не было подписано?
Нет, это не обязательно, но это механизм, позволяющий вам гарантировать подлинность сборки. Это позволяет вам убедиться, что сборка не была подделана и, действительно, происходит от этого автора. Это также необходимо, если вы хотите поместить их в GAC.
Какие недостатки существуют при подписании сборок - это вызывает задержки?
Подписанные сборки могут загружать только другие подписанные сборки. Также они привязаны к определенной версии, что означает, что вам нужно использовать перенаправления привязки или перекомпилировать приложение, если вы хотите использовать другую версию. Кроме того, из-за проверки подписи снижается производительность, но она настолько мала, что вам не о чем беспокоиться.
Вам нужно подписывать сборки, если вы хотите поместить их в GAC .
Если вы подписываете исполняемый файл, то любые библиотеки классов, на которые он ссылается, также должны быть подписаны. Это может быть сложно, если вы используете стороннюю библиотеку (особенно если вам нужно использовать элемент управления ActiveX или аналогичный).
Ричард Граймс написал хороший семинар по безопасности в .NET, который включает в себя главу об этом: Security Workshop
Причиной того, что все сборки были подписаны одним и тем же файлом .snk, могло быть то, что он использовал модульное тестирование с покрытием кода. Чтобы иметь возможность выполнять покрытие кода (по крайней мере, с помощью инструментов, встроенных в тестовую версию Visual Studio 2005) и если сборки подписаны, необходимо указать, какие файлы .snk используются для подписи, но я думаю, что вы можете только укажите один файл .snk для всего решения, поэтому, если вы подписываете различные библиотеки классов разными файлами .snk, вы можете проверять покрытие кода только для одного из них одновременно.
Очень важная причина подписать сборку, чтобы вы могли быть уверены, что это ваша сборка. Поскольку закрытый ключ принадлежит вам, никто другой не может подписать сборку этим же ключом. Это означает, что, когда вам известен открытый ключ сборки (вы можете извлечь его с помощью GetType().Assembly.GetName().GetPublicKey()функции), сборка принадлежит вам и не была подделана.
Несмотря на все случаи подписания DLL, DLL следует подписывать только по двум причинам.
1. Управление версиями
2. Аутентификация
а. Управление версиями обозначает версию, на которой была собрана библиотека dll, и в то время, когда они помещаются в GAC, могут существовать две dll с одинаковыми именами, но с другой версией.
б. Аутентификация обозначает, не является ли DLL-файл измененным и существует ли он таким же, когда он был создан.
Если вы хотите больше узнать об основах и подписи DLL, вы можете обратиться сюда
В дополнение к существующим ответам я бы добавил, что вы должны использовать подпись, когда ваша DLL будет динамически загружаться и использоваться сторонним программным обеспечением. Это не техническое требование само по себе, но рационально, поэтому очень распространено, чтобы сторонний производитель программного обеспечения применял такую политику из соображений безопасности.
Примеры, где вы должны подписать сборку: