Зачем использовать строго названные сборки?

Question

Каковы преимущества использования мощных именованных сборок?

Что нельзя сделать с помощью обычной сборки?

Answer 1

Позвольте мне вначале перечислить преимущества сильного наименования вашей сборки:

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

2. Сильное именование гарантирует уникальное имя для этой сборки. Таким образом, никто другой не может использовать такое же имя сборки.

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

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

Подробнее о строгих именах от Microsoft см. В Сборки со строгими именами ( MSDN ).

Answer 2

Что нельзя сделать с помощью обычной сборки?

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

Если вы используете автоматические настройки приложения или пользовательской области приложения, предоставляемые VisualStudio (унаследованный System.Configuration.ApplicationSettingsBase), тогда EXE-файл со строгим именем создаст ровно 1 каталог внутри% LOCALAPPDATA% с именем, например, «YourApplication.exe_StrongName_kjsdfzsuzdfiuzgpoisdiufif» где-то, где-то-то-где-то-то-то-значимом месте » EXE находится.

Но без строгого имени местоположение (= путь) EXE будет использоваться для создания значения хеша, которое уже отличается в сборке DEBUG и RELEASE, создавая много каталогов внутри% LOCALAPPDATA% с именем, подобным "YourApplication.exe_Url_dfg8778d6fs7g6d7f8g69sdf". Это делает его непригодным для развертываний ClickOnce, где каталог установки меняется при каждом обновлении.

Answer 3

Я хотел бы добавить, что без строгого имени нельзя использовать перенаправления привязки в файлах конфигурации.

Это не будет работать:

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="null" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

Вам нужен токен открытого ключа

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

Answer 4

Просто пример: я бы хотел дать ответ, сделав больший акцент на безопасности . В случае, если мы создаем сборки с исходным кодом, который мы не хотим использовать повторно для третьей стороны, но хотим, чтобы он был тестируемым, мы можем строго подписать сборку и сделать внутренние компоненты видимыми только для тех сборок с та же подпись.