Ссылки проекта проекта dotnet pack

Мне очень нравится разделение функциональности на нескольких сборках, например, фасад для поставщика данных, контракты для поставщика данных и сама реализация поставщика данных... на мой взгляд, это облегчает unit test индивидуальную компоненты функциональности и легко заменять одну вещь в будущем (в случае моего примера это облегчает обмен данными).

Если я создаю решение с тремя проектами и использую ссылки на проекты, когда я создаю dotnet-сборку на сборке записей, все ссылки копируются в выходную папку. Когда я dotnet упаковываю проект сборки записи для создания пакета NuGET, в пакет NuGET входят только сборка (не контракты или поставщик данных)

Это выглядит по дизайну; документация для .NET Core dotnet-pack гласит, что

Ссылка на проект-проект не упакована внутри проекта.    В настоящее время у вас должен быть пакет на один проект, если у вас есть зависимости между проектами.

Мой вопрос: почему это так? Если я хочу отделить свой код от логических сборок, я вынужден либо создавать отдельные пакеты NuGET, либо ссылаться на них, либо просто подрезать весь мой код в одну сборку. Есть ли способ включить ссылки на проект в пакете NuGET?

Я использую VS2017/.NET Core v1.1 (csproj, а не xproj)

Ответы

Ответ 1

Немного поздно, но позвольте мне попытаться объяснить, почему я не хочу, чтобы сборники связанных ссылок были упакованы в пакет ввода по умолчанию.

Инфраструктура .NET Core предназначена для модульной работы и основана на модели пакетов. В основном,.NET Core SDK и dotnet-мультиплексор (основной загрузочный сервер .NET и хост-процесс) работают сначала с пакетами и их метаданными, а не с dll, которые являются основными CLR, которые напрямую связаны с ними. Таким образом, в .NET Core на самом высоком уровне идентификатор пакета/версия является первичной, а имя/версия dll внутри пакета является вторичной.

Сам пакет (несмотря на то, что он является архивом с некоторым контентом) - это абстракция, которая идентифицируется по имени и версии.

Предположим, что мы имели желаемое поведение dotnet pack, и все ссылки упакованы в один и тот же пакет ввода. Теперь, если у нас есть цепочка ссылок на проекты, мы получаем единый пакет со всеми DLL внутри. Вероятно, он подходит для наших нужд, но он также нарушает:

  • Модульная идея .NET Core (поскольку мы должны думать о DLL, скорее чем абстрактный пакет, который является только идентификатором/версией - это добавит много путаницы и сложности, поскольку нам также понадобится возможность не иметь пакет "все-в-одном", избегать дублирования DLL, обрабатывать разрешение DLL в случае множественного версии и т.д.).
  • SRP (когда некоторые из требуемые DLL необходимо перестроить, нам нужно будет обновить весь пакет).

Что касается вопроса, я думаю, что возможный способ добиться этого - использовать пользовательский файл .nuspec, где вы можете указать DLL, которые хотите упаковать.

<PropertyGroup>
    <NuspecFile>App.nuspec</NuspecFile>
</PropertyGroup>

После этого dotnet pack создаст пакет по отношению к MyPackage.nuspec.

Кроме того, если у вас есть 3 проекта с контрактами и реализациями, и вы не хотите добавлять 3 ссылки на пакеты, вы можете создать пакет, который просто имеет эти 3 в качестве зависимостей и ссылается на один пакет.

Чтобы обернуть все, текущая модель Package-per-Project довольно проста и по-прежнему остается гибкой для пользовательских прецедентов.