Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Строгое именование относится к подписи сборки с ключом, создающим сборку со строгим именем. Если сборке присваивается строгое имя, это создает уникальный идентификатор на основе имени и номера версии сборки, что может помочь предотвратить конфликты сборок.
Недостатком строгого именования является то, что платформа .NET Framework в Windows обеспечивает строгую загрузку сборок после строгого именования сборки. Ссылка на сборку с строгим именем должна точно соответствовать версии загруженной сборки, заставляя разработчиков настраивать перенаправления привязки при использовании сборки:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Когда разработчики .NET жалуются на строгое именование, чаще всего они говорят о строгой загрузке сборок. К счастью, эта проблема изолирована от .NET Framework. .NET 5+, .NET Core, UWP и большинство других реализаций .NET не имеют строгих ограничений на загрузку сборок, что является главным недостатком строгого именования.
Один из важных аспектов строгого именования в .NET Framework заключается в том, что это распространяющийся эффект: сборка со строгим именем может ссылаться только на другие сборки со строгими именами. Если библиотека не имеет строгого имени, приложения и библиотеки .NET Framework, которым требуется строгое именование, не могут использовать его.
Преимущества строгого именования в .NET Framework:
- На эту сборку могут ссылаться и использовать другие сборки со строгими именами.
- Сборку можно хранить в глобальном кэше сборок (GAC).
- Сборку можно загрузить параллельно с другими версиями сборки. Загрузка сборок в параллельном режиме обычно требуется в приложениях с архитектурами подключаемых модулей.
Строгое именование не имеет преимуществ для .NET Core/5+. Компилятор C# выдает предупреждение CS8002 для сборок со строгим именем, ссылающихся на неименованные сборки. Это предупреждение можно отключить только для библиотек, предназначенных только для .NET Core/5+.
Когда следует присваивать строгое имя библиотекам .NET
Строгое именование не требуется для библиотек, предназначенных только для .NET Core/5+. Следует строго назвать библиотеки .NET с открытым исходным кодом, если их целевые объекты включают .NET Framework или .NET Standard.
Замечание
Это руководство предназначено для общедоступных распределенных библиотек .NET, таких как библиотеки .NET, опубликованные на NuGet.org. Строгое именование не требуется большинству приложений .NET и не должно выполняться по умолчанию.
✔️ Рассмотрите строгое именование сборок библиотеки, если вы используете только .NET Framework или .NET Standard.
Строгое именование не влияет на современные среды выполнения .NET. Если библиотека предназначена только для современной платформы .NET, вам не нужно строго называть сборки.
Если вы используете несколько целевых объектов в .NET Framework/.NET Standard и современной .NET, то следует строгое имя для всех целевых платформ.
✔️ Рекомендуется добавить пару ключей строгого именования (учетную и частную) в систему контроля версий.
Общедоступная пара ключей позволяет разработчикам изменять и перекомпилировать исходный код библиотеки с тем же ключом.
Не следует делать пару ключей strong naming общедоступной, если она использовалась в прошлом для предоставления специальных разрешений в сценариях с частичным доверием. В противном случае может быть компрометация существующих сред.
Если вы не можете зарегистрировать пару открытого и закрытого ключей, зарегистрируйте открытый ключ и используйте открытое подписание для обычных сборок. Общедоступная подпись по-прежнему позволяет разработчикам перекомпилировать и использовать библиотеку в большинстве сценариев.
Это важно
Если необходимо удостоверить личность издателя кода, рекомендуется использовать Authenticode и подписание пакетов NuGet. Безопасность доступа к коду (CAS) не должна использоваться в качестве устранения рисков безопасности.
✔️ Рассмотрите возможность увеличения версии сборки только при изменении основных версий, чтобы помочь пользователям уменьшить частоту обновления перенаправлений привязок и их количество.
Узнайте больше о управлении версиями и версии сборки.
❌ НЕ добавляйте, удаляйте или изменяйте ключ строгого именования.
Изменение ключа строгого именования сборки изменяет идентификацию сборки и ломает скомпилированный код, который его использует. Для получения дополнительной информации см. изменения, нарушающие бинарную совместимость.
❌ НЕ публикуйте строго именованные и нестрого именованные версии библиотеки. Например, Contoso.Api и Contoso.Api.StrongNamed.
Публикация двух пакетов разделяет экосистему разработчика. Кроме того, если приложение оказывается зависимым от обоих пакетов, разработчик может столкнуться с конфликтами имен типов. Что касается .NET, они представляют собой разные типы в различных сборках.
Примеры строгого именования
Следующие популярные библиотеки .NET с открытым кодом используют строгое именование и имеют пару ключей, зарегистрированную в системе управления версиями. Они могут служить ссылками при настройке строгого именования для библиотеки:
- Newtonsoft.Json (лицензия MIT) имеет сильно именованное имя и регистрирует свою пару ключей в системе управления исходным кодом.
- AutoMapper (лицензия MIT) имеет строгое имя и проверяет свою пару ключей в системе управления версиями.
- NodaTime (лицензия Apache 2.0) имеет строгое именование и сохраняет свою пару ключей в системе контроля версий.
Дополнительные сведения о том, как команда .NET подходит к строгому именованию во всех библиотеках среды выполнения и основных библиотек, см. в статье "Строгое имя" в репозитории dotnet/runtime.