Что следует учитывать при подписании строгого имени управляемого приложения?

Question

Я хочу строго назвать управляемое приложение, которое ссылается на многие управляемые сборки и компоненты ActiveX и COM (написанные на C ++) через взаимодействие. И поскольку сборка со строгим именем не может ссылаться на сборку со слабым именем, не могли бы вы сказать, к каким проблемам я должен быть готов, с чем вы столкнулись, особенно при работе с этими взаимодействиями ActiveX и COM?

Решение для этого приложения большое. Он состоит из 50+ проектов под управлением C #, Vb.net, нативного C ++ и управляемого C ++ / CLI. Поэтому, чем больше информации, реальных историй вы дадите, тем лучше я смогу подготовиться и избавиться от головной боли.

Спасибо.

Answer 1

В действительности нет ничего проблемного, кроме надежного хранения файла .snk.

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

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

См. этот вопрос и этот совершенный ответ для подробностей выше.

Answer 2

До сих пор у меня не возникало проблем, связанных со строгими именами (также с использованием сборок взаимодействия COM). Если у вас есть сторонняя сборка, у которой нет строгого имени, вы можете подписать ее самостоятельно, что позволит вам сделать все сборки со строгим именем.

Конечно, создание строгой именованной сборки взаимодействия не защищает базовые библиотеки DLL COM, подлежащие изменению или замене, поэтому «защита» от строгого имени не распространяется на компоненты COM, даже если взаимодействие сборка строго названа.

Answer 3

У меня пока нет реального опыта с такого рода визуальным студийным решением. Но я надеюсь, что информация здесь и здесь может дать вам некоторые идеи для ваших компонентов взаимодействия.