Это на самом деле не о .NET Core против "старого" стиля csproj. Проекты SDK могут создавать проекты .NET Framework, поэтому не ограничиваются .NET Core. Это также не относится к SDK-проектам против "старых" проектов, поскольку "старые" проекты могут использовать PackageReference.
Таким образом, если у вас есть решение с несколькими файлами packages.config, пакеты будут восстановлены в одну папку пакетов, но packages.config не поддерживает транзитивные зависимости и завершается ошибкой, если не указана точная запрашиваемая версия. имеется в наличии. Таким образом, легко перебрать каждый проект, прочитать packages.config и найти точный пакет в папке пакетов решений. Пакет также должен существовать в папке глобальных пакетов, но есть сценарии, в которых это не может быть правдой.
PackageReference извлекает транзитивные зависимости и выбирает разные версии, когда возникают конфликты или запрашиваемая версия недоступна. Однако, когда восстановление прошло успешно, он записывает файл obj\project.assets.json
, который вы можете прочитать. В нем перечислены полный график восстановления и точная версия каждого используемого пакета. Используя эту информацию, вы можете найти точную версию каждого пакета, который используется в папке глобального пакета.
Насколько я понимаю, в npm обычно, если не требуется, помещать файл лицензии в пакет, который сохраняется на компьютере пользователя. К сожалению, это не относится к пакетам nuget. Но, по крайней мере, используя файл активов, вам не нужно выяснять дерево зависимостей или беспокоиться о том, что ваша логика выбора версии отличается от логики nuget.