PackageReference или ProjectReference на компонент внутри того же решения? - PullRequest
Новая
       18

PackageReference или ProjectReference на компонент внутри того же решения?

1 голос
/ 30 апреля 2019

Давайте рассмотрим сценарий, в котором у нас есть два проекта .NET Standard, для которых мы хотим представить и создать пакеты NuGet для:

LibrarySolution

ClassLibrary1 (CL1)

∟ ClassLibrary2 (CL2)

Важно отметить, что CL1 имеет ProjectReference для CL2.

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

Проблема возникает, когда нам необходимо определить в рамках LibrarySolution, какая версия CL2 требуется в CL1, поскольку у нас есть прямая ссылка на проект.

На ум приходят два следующих подхода:

  1. Ведение ссылок на проекты в решении, что означает, что нам нужно будет сохранить версию пакета в файле csproj, зафиксировать изменения версий и т. Д., Чтобы ограничения версий и требования к зависимостям были правильными (в настоящее время мы работаем с версиями) в конвейере CI и текущая версия хранится там, а не в коде).

  2. Преобразовать зависимость от CL2 в PackageReference. Таким образом, CL1 всегда будет зависеть от версии CL2, которая уже была опубликована. Тем не менее, это будет означать, что вам придется потратить все силы на публикацию и обновление пакетов NuGet (утверждение PR, слияние, CI и т. Д.), Что может занять очень много времени.

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

Ответы [ 2 ]

0 голосов
/ 01 мая 2019

Прежде всего, вы все делаете правильно с ProjectReference. Нет никаких причин для того, чтобы два проекта в одном решении даже знали о существовании пакета другого. Теперь, когда у вас есть CL1 и CL2 в одном и том же решении, я полагаю, что для CL1 требуется обновленная версия CL2.

С учетом предыдущего вы можете просто сгенерировать ваши пакеты сборки, добавив <GeneratePackageOnBuild>true</GeneratePackageOnBuild> тег, и MSBuild изменит его на зависимость NuGet до последней версии в пакете.

0 голосов
/ 01 мая 2019

По моему опыту, самый чистый подход с наименьшим количеством головной боли - это # ​​2 с использованием PackageReference. Да, есть больше накладных расходов, но это делает все явным, и это официально поддерживаемое решение.

(Если вы колеблетесь с этим маршрутом, потому что вам нужно обновлять CL1 каждый раз, когда вы меняете CL2, возможно, вам нужно подумать, имеет ли смысл ваша компонентизация. В идеале CL2 должен определять относительно стабильные интерфейсы и может быть изменен независимо от CL1. )

В противном случае есть 2 подхода, которые вы не упомянули:

  1. Включая обе библиотеки в одном пакете NuGet. Хотя это официально не поддерживается с существующим инструментарием, здесь описаны несколько обходных путей: https://github.com/NuGet/Home/issues/3891

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

...