Следует ли подписывать собрания?

Question

У нас есть набор компонентов COM, разработанных в VC++. Когда ссылка на такой компонент добавляется в .NET-проект, Visual Studio создает сборку interop. Сейчас у нас есть набор таких сборок.

При выполнении нашей ежедневной сборки мы подписываем все созданные двоичные файлы с цифровой подписью. Сборки Interop не подписаны, так как мы не считаем себя авторами - каждый может использовать Visual Studio и создавать те же сборки.

Должны ли мы также подписывать сборки соединений? Должны ли мы также подписывать их с сильным именем (утилита sn.exe)? Каковы причины этого?

Answer 1

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

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

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

В зависимости от того, насколько сложны сборки Interop, вы можете сгенерировать прокси-код в отдельный файл .CS/.VB и скомпилировать его непосредственно в сборку. Тогда вам не придется беспокоиться о проблемах с сильным именем.

Answer 2

Мы используем Sn.exe для сильного имени наших сборников interop, созданных инструментами, в качестве оберток вокруг объектов COM. Нам нужно сделать это, так как сборка, загружающая их, будет подписана, поэтому их нужно подписать.

Для генерации сборки взаимодействия, которые мы используем:

tlbimp Some_COM.dll /delaysign /publickey:"Some_PublicKey.snk" /out:Some_COM2Lib.dll" 

Очевидно удалить/DelaySign если вы полностью подписания.

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

Answer 3

Заменить «ОткрытыйКлюч» на «файл_ключа»:

tlbimp Some_COM.dll /delaysign /keyfile:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"