У меня есть следующие требования для библиотеки. NET, которая должна быть отправлена через NuGet:
- должна быть совместима с. NET Framework и. NET Основные приложения
- должен быть подписан / иметь строгое имя, чтобы разрешить использование в приложениях, которые подписаны / имеют строгое имя самостоятельно
Подход, который я использовал для удовлетворения этих требований, заключался в том, чтобы нацелиться. NET Стандарт в качестве целевой платформы и подпишите заявку. Теперь начались осложнения.
Есть еще одна библиотека, от которой зависит моя библиотека: не со знаком / со строгим именем (в этом. NET Стандартный совместимый вариант). Это приведет к возникновению исключения во время выполнения, например:
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
На этом этапе я вижу следующие варианты для продолжения, но я не уверен, какой из них выбрать и есть ли лучший способ делая это.
Вариант 1
Не подписывайте библиотеку и оставьте ее пользователю пакета для подписи библиотеки (вместе с зависимой библиотекой), когда нужно. Простой и понятный, но создает много усилий для разработчиков, которые полагаются на библиотеки со строгими именами (например, имеют собственные подписанные приложения).
Вариант 2
Создать отдельные проекты и пакеты NuGet для. NET Framework и. NET Core. Строгое название проекта / пакета для. NET Framework, но не для. NET Core. Преимущество: разработчики могут выбрать пакет NuGet, который соответствует потребностям их приложений. Недостаток: для меня, как для поставщика библиотек, требуются усилия, поскольку два проекта, которые на 99% идентичны, должны поддерживаться параллельно. Кроме того, имея два различных пакета NuGet, один для. NET Framework и один для. NET Ядро кажется странным, потому что вместо этого следует использовать NET Standard.
Опция 3
Подпишите и библиотеку, и зависимую библиотеку и распространите их вместе с одним и тем же пакетом NuGet. Возможно, но подписание сторонней библиотеки и распространение ее через NuGet звучит «хакерски». Также не уверен насчет последствий, если разработчик будет использовать ссылку на ту же библиотеку в другой версии и / или неподписанный вариант этой же библиотеки.
Любые рекомендации или другие идеи, как решить эту ситуацию