C#: зачем подписывать сборку?

в некотором коде C#, который я взял на себя (в Visual Studio 2005), я заметил, что все сборки подписаны одним и тем же .

  • Почему предыдущий автор подписал сборки таким образом?
  • подписание сборки и было бы неправильно не подписывать?
  • какие недостатки есть в подписание сборок-это вызывает задержки?
128
assemblies c#

5 ответов

почему предыдущий автор подписал сборки таким образом?

понятия не имею, может быть, он хотел, чтобы все его сборки были подписаны одним и тем же ключом.

необходимо ли подписывать сборки и что было бы неправильно, если бы не подписывать их?

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

какие недостатки есть в сборках подписи - это вызвать задержку?

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

151

вам нужно подписать сборки, если вы хотите поместить их в GAC.

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

Ричард Граймс написал хороший семинар О безопасности в .NET и это включает в себя главу об этом: Мастерская Безопасности

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

31

очень важная причина подписать сборку, чтобы вы могли быть уверены, что это ваша сборка. Поскольку закрытый ключ является вашим, никто другой не может подписать сборку с тем же ключом. Это означает, что когда открытым ключом сборки является тот, который вы знаете (вы можете получить это с помощью GetType().Assembly.GetName().GetPublicKey() функция), сборка ваша, и она не была подделана.

15

несмотря на все обычаи подписания dll, dll должна быть подписана только по двум причинам

1. Версионирование

2. Проверка подлинности

a. Управление версиями означает, какая версия dll была построена, и при нажатии их в GAC две dll с тем же именем могут существовать, но другая версия

b. Аутентификация указывает, не является ли dll измененной и существует ли то же самое, когда она была создан.

Если вы хотите больше узнать об основах и подписи dll, вы можете обратиться здесь

1

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

примеры, где вы должны подписать сборку:

  • разработка расширения оболочки Windows / Проводника Windows, как: расширение контекстного меню Проводника Windows
  • разработка расширений Visual Studio, например: GUI мастера шаблонов проектов/элементов
0