Почему ссылки на сторонние сборки в проекте библиотеки классов необходимо снова добавлять в другие проекты, ссылающиеся на проект библиотеки на С#?

Извините за такой наивный вопрос, который мне даже трудно описать. У меня есть проект classlibrary, скажем, «A», в котором есть логика, на которую я ссылаюсь в проекте «B» через ссылку на сборку (добавлена ​​ссылка на dll проекта «A»), который в основном является проектом модульного тестирования. В проекте «А» используются некоторые сторонние сборки, такие как Serilog, Newtonsoft. Итак, теперь в модульном тесте в проекте «B», когда я вызываю методы класса из проекта «A», я вижу, что мой тест завершается сбоем с исключением файла, не найденного, и он ссылается на файлы сборки, такие как Serilog и NewtonSoft, которые были там в проекте «А». Поэтому я был озадачен тем, что моему проекту «B» не нужны никакие из этих библиотек напрямую, они нужны только проекту «A». Но все же, чтобы удалить ошибку одну за другой, я добавил те же ссылки на сборки в проект «B», и это устранило ошибку.

Но я не понял, зачем мне нужно было снова добавлять те же сборки в Project 'B'. Это противоречит цели, когда я пытаюсь абстрагировать логику в отдельном проекте, чтобы другим проектам не приходилось повторять одно и то же? С этой логикой теперь каждый другой проект модульного тестирования, который я собираюсь написать в будущем, ссылаясь на проект «А», потребует такой же ссылки на сборку, которая кажется накладной.

Если это актуально: проект моей библиотеки классов «A» — это проект на основе .NET Standard 2.0, а проект «B» — это проект типа консольного приложения .NET Core 2.1.

Если это повторяющийся вопрос, пожалуйста, направьте меня, я хочу понять, как это работает. Если за этим поведением стоит концепция C#, сообщите мне, и я прочитаю об этом подробнее. Также зависит ли это поведение от типа сторонней библиотеки, которую мы используем, например, от ведения журнала по сравнению с любым другим типом библиотеки?

Заранее спасибо!


person Vikas    schedule 16.06.2018    source источник
comment
Это известное ограничение текущей поддержки инструментов для .netstandard. Он просто недостаточно умен, чтобы знать, как копировать зависимые сборки .netstandard. Это должно было быть исправлено в VS2017, но этого не произошло. Для выполнения этой работы была установлена ​​новая веха, ее название — «Неизвестно». Обходной путь, который вы нашли, является правильным прямо сейчас.   -  person Hans Passant    schedule 17.06.2018
comment
Спасибо Ганс за быстрый ответ. Я рад узнать, что это проблема с инструментами, а не с тем, как я это использовал. :) Надеюсь, это скоро будет исправлено. Еще раз спасибо.   -  person Vikas    schedule 17.06.2018
comment
Я думал, что на днях играл с ядром и стандартом, и все nugets были не только скопированы, но и изначально вызывались без проблем, и мне пришлось особо отметить зависимости, чтобы они не были   -  person TheGeneral    schedule 17.06.2018
comment
Спасибо Генералу за ответ. Но, к сожалению, это не то, что я испытал со сторонними библиотеками, которые я использовал. Я также обновил свой файл vs2017. Не уверен, что это актуально, но мой проект «B» - это проект xunit.   -  person Vikas    schedule 17.06.2018
comment
Можете ли вы взглянуть на этот ответ? Похоже, это может быть та же проблема. stackoverflow .com/questions/50771569/   -  person Alex Ghiondea - MSFT    schedule 19.06.2018
comment
Привет, Алекс, это похоже на ту же проблему, когда зависимости не копируются между стандартом .NET и консольным приложением .net core. Я попробовал первое решение, но оно не помогло. Поэтому я использую второй вариант прямого добавления dll. Надеюсь, что эта проблема скоро будет решена.   -  person Vikas    schedule 19.06.2018
comment
Не могли бы вы поделиться решением, для которого первый вариант не сработал? Я рад, что второй вариант работает для вас!   -  person Alex Ghiondea - MSFT    schedule 20.06.2018
comment
Я могу попытаться создать небольшой образец приложения, чтобы воспроизвести эту проблему. Скажите, могу ли я воспроизвести, где я могу загрузить решение?   -  person Vikas    schedule 20.06.2018
comment
Можете ли вы создать репозиторий на GitHub и разместить там решение?   -  person Alex Ghiondea - MSFT    schedule 20.06.2018