#nuget #.net-core
#nuget #.net-core
Вопрос:
Я бы ожидал, что какой-то фильтр будет существовать на веб-сайте или в консоли.
Ответ №1:
К сожалению, сейчас это непросто. На Github NuGet открыта проблема с добавлением фильтра на веб-сайт.
Прямо сейчас лучший способ определить, будет ли пакет работать с .NET Core, — это изучить поддерживаемые им фреймворки в разделе зависимостей.
Если в списке указан .NETStandard, пакет поддерживает .NET Core через .Стандарт платформы NET:
Если в разделе зависимостей пакета не упоминается.NETStandard или раздел зависимостей полностью пуст, он не поддерживает .NET Core:
Комментарии:
1. Я не понимаю, почему отсутствие зависимостей означает, что пакет не поддерживает .NET Core?
2. @Vukoje Пользовательский интерфейс немного сбивает с толку и должен быть обновлен IMO. Отсутствие зависимостей означает что-то вроде «он поддерживает .NET Framework без каких-либо дополнительных необходимых пакетов». Поскольку .NET Standard будет указан в качестве целевого объекта зависимости, в настоящее время это самый простой способ определить, поддерживает ли он .NET Core.
3. Пакеты NuGet, которые включают PCL, также поддерживают .NET Core, но не будут отображаться в списке, предложенном выше. К сожалению, часто бывает трудно определить, какие библиотеки отправляют PCL из сводки на nuget.org . Кроме того, nuget потребует, чтобы вы включили инструкцию «imports» в свой project.json, чтобы использовать пакет, созданный для профиля PCL.
4. Это неправильно. Если вы посмотрите RestSharp 106.6.9 в диспетчере пакетов Nuget, вы не увидите никаких зависимостей, но если вы откроете пакет в Nuget package Explorer, вы увидите это. Поддерживается NETStandard 2.0.
5. @bech Когда я смотрю на nuget.org/packages/RestSharp он содержит список «.NETStandard 2.0» в разделе Зависимостей. Может быть, мой ответ сформулирован запутанно?
Ответ №2:
Настройте проект .NET Core в нужной вам версии. Я сохраняю проекты 1.1 и 2.0 для дальнейшего использования. Затем попробуйте добавить nuget в проект.
Например, ASPOSE НЕ будет добавляться к проекту 1.1, но будет добавляться к проекту 2.0.
Самый простой маршрут в краткосрочной перспективе, пока они это как-то не исправят.
Очевидно, что это не гарантирует, что он все еще работает, но дает вам хорошую идею, если его api совместим.