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

107

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

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

c# .net

— разработчик
источник

92

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

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

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

— Кайл Розендо
источник

1

Вы уверены по пункту 4? Я думаю, может быть, это поведение недавно изменилось. Я попытался завершить загрузку сборки со строгим именем, изменив ее, но она загрузилась без происшествий.

— Йенс

19

Что касается №4, это неверно. Он не предназначен для защиты от взлома. См. Blogs.msdn.com/b/shawnfa/archive/2005/12/13/… для получения дополнительной информации.

— Колин Бауэрн

1

@ RobV8R 90% наших зависимостей имеют открытый исходный код, закрытые ключи находятся в общедоступных репозиториях git (в соответствии с рекомендациями Microsoft) и доступны всем, кому они нужны.

— trampster

1

@ RobV8R Вы не можете использовать здесь слово "скомпрометировано", это будет означать, что оно изначально задумано как секрет. Рекомендации Microsoft заключаются в том, что закрытый ключ должен храниться в вашем общедоступном репозитории. Закрытые ключи не скомпрометированы, они намеренно опубликованы. Учитывая, что закрытые ключи известны и предназначены для использования людьми, модифицирующими код с открытым исходным кодом родительских проектов (в противном случае лицензия будет нарушена во многих случаях), люди, делающие это, будут использовать другой номер версии, но тот же ключ, в этом если потребуется перенаправление привязки.

— trampster

1

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

— trampster

9

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

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

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

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

— упругий76
источник

5

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

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

  <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>

— томасат
источник

9

Перенаправления привязки не нужны, если у вас нет строгого имени.

— trampster

0

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

— Рики Юсеф
источник