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

Ответ 1

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

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

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

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

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

Подробнее о сильном названии от Microsoft находится в Strong-Named Assemblies (MSDN).

Ответ 2

Что не может быть сделано с обычной сборкой?

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

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

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

Ответ 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>

Ответ 4

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