Должны ли dll’ки из nuget пакетов автоматически копироваться во все проекты с косвенными ссылками в VisualStidio?

Question

[Руслан]

Поясню суть вопроса:
Есть в одном решении есть проектА, в котором создается класс MyRedis, который ссылается на nuget пакет StackExchange.Redis, в этом же решении есть проектБ, который ссылается на проектА, не содержит пакета StackExchange.Redis и нигде явно к классам Redis не обращается, но зато создает экземпляр класса MyRedis.
В моем представлении, при построении должно произойти следующее: VS должен определить зависимости и собрать в папке bin проектаБ все необходимые dll’ки: и проектаА и StackExchange.Redis. (так и происходит с некоторыми nuget пакетами)
Но у меня почему-то dll’ки StackExchange.Redis не оказываются в папке bin проектаБ и запуск не выполняется, но если руками эти dll’ки скопировать, то все в порядке.
Итого, вопрос: как все таки, должно происходить копирование dll’ок пакета StackExchange.Redis в дочерние проекты или нет? Это у меня VS глючит, или все таки я имею неверные ожидания относительно автоматического копирования dll’ок?
Спасибо за внимание.

Comments

[NewDevLab]

Когда у меня такое было, особо не разбирался, просто добавил недостающую зависимость в основной проект.
После этого все сборки копировались в выходной каталог.

Answer 1

[Руслан]

Я провел эксперимент: в решении два проекта, первый проект (.net standard 2.0) ссылается на nuget пакет, второй проект (.net framework 4.7.2) ссылается на первый. Построение решения происходит успешно, но при запуске второго проекта возникает ошибка: не удалось загрузить сборку из nuget пакета. от сюда вывод - при построении зависимости из nuget пакетов, которые непосредственно не содержатся в проекте не копируются в выходную папку.

Еще я нашел статью: https://terryaney.wordpress.com/2018/05/06/msbuild... в которой это подтверждается и решение заключается в использовании MSBuild со своей конфигурацией. А вот подключать nuget пакеты ко всем проектам - подход не самый лучший (хотя самый простой).

Я продолжил экспериментировать:
Создал нулевой проект (.net standard 2.0) на который ссылается только первый проект. При построении и запуске второго проекта все зависимости были разрешены, приложение запустилось без проблем.

И еще один эксперимент:
Я создал четвертое приложение, но уже .net core 2.1, которое ссылается только на проект 1, и к моему удивление при его сборке и запуске все зависимости, включая nuget пакет были разрешены, запуск произошел успешно.

Видимо, .net standard и .net core проекты строятся не так, как это делают .net framework проекты.

Comments

[#]

второй (или третий?) эксперимент даже интереснее. для эрудиции (если вдруг пропустили новость ))

https://habr.com/ru/company/raiffeisenbank/blog/451136/

в общем

Видимо, .net standard и .net core проекты строятся не так, как это делают .net framework проекты.

это точно будет отличаться. при проектировании .Net Core (и как мы знаем уже, это была подготовка замены традиционному .Net) с самого начала, был большой акцент, на использование разных версий фреймвока в одной ОС, а так же разных зависимостей в проекте, и тд, и тп... ну вполне очевидно, что был большой анализ положительного опыта в этих областях, из линукс.. (я не говорю что там все идеально ;))).. просто МС стал более агрессивно впитывать чужой успешный опыт )))

[#]

Видимо, .net standard и .net core проекты строятся не так, как это делают .net framework проекты.

.net standard это подмножество, гарантированно совместимое и с .Net Framework (традишен на десктопе) и с .Net Core

думаю все определяет целевой проект. если это .Net Framework - сборку будет делать MSBuild. если Net Core - то сборка идет инструментами корки