Это звучит как проблема с тем, как разрешение сборки работает между временем сборки и временем выполнения (которое работает через подход «приманка и переключение»). Когда вы сталкиваетесь с подобными проблемами с транзитивными зависимостями, первое, что нужно попробовать, это заставить вашу библиотеку присоединиться к группе приманок и сменить , объявив , что у нее могут быть разные потребности в разныхTFMs. Это довольно легко, к счастью;часто это просто означает изменение:
<TargetFramework>netstandard2.0</TargetFramework>
на
<TargetFrameworks>netstandard2.0;net472</TargetFrameworks>
Теперь это пакет с многоцелевым таргетингом. Когда создается приложение (exe и т. Д.) (Не приложения, предназначенные только для библиотек), оно проверяет все дерево зависимостей и выясняет, какая наиболее подходящая версия библиотеки DLL для каждого пакета в отдельности. . Это означает, что, если приложение нацелено на net472
, net48
и т. Д. - они получат вашу сборку net472
, которая, вероятно, сама имеет несколько другие цепочки (даже если вы их не видите). Если приложение предназначено для .NET Core, они получат версию вашего пакета netstandard2.0
и все зависимости , которые есть у .
Примечание: для лучшего охвата вы может захотеть немного отбросить TFM:
<TargetFrameworks>netstandard2.0;net461</TargetFrameworks>
Причина этого в том, что net461
, net462
и т. д. утверждают, , что могут обрабатывать netstandard2.0
- поэтому, если приложение нацелено на net461
, а ваш пакет нацелен на netstandard2.0;net472
, тогда «лучшее» совпадение - netstandard2.0
, которое, по-видимому, все еще не будет работать. Конечно, вы можете иметь столько, сколько вам нужно (и даже изменить последующие ссылки для каждого) - возможно:
<TargetFrameworks>netstandard2.0;netcoreapp3.0;net461;net472</TargetFrameworks>
Обычно вы только добавляете TFM к:
- использование дополнительных функций, доступных на определенном TFM, или
- платформ, которые не включены в ваш текущий список, или
- fix bait-and-switch /проблемы зависимости