Решение, необходимое для ссылки на пакеты Nuget из проектов в одном решении - PullRequest
Новая
       51

Решение, необходимое для ссылки на пакеты Nuget из проектов в одном решении

0 голосов
/ 18 октября 2018

У меня есть одно решение, полное проектов, которые должны быть использованы в моей организации как общие пакеты nuget.Решение включает в себя один репозиторий git, и у нас есть TeamCity, выполняющий наши сборки для нас, хотя мы не слишком продвинуты в том, что мы вручную запускаем сборки Teamcity, когда мы готовы сгенерировать / опубликовать новый пакет Nuget для данного проекта врешение, каждый проект имеет свою собственную конфигурацию сборки TeamCity.

При сборке проекты генерируют пакеты nuget с помощью тега .csproj <project/>: GeneratePackageOnBuild мы также контролируем управление версиями с помощью тегов version, которые заполняются черезстроить свойства из TeamCity.Это прекрасно работает.Где мы сталкиваемся с проблемами - это управление ссылками / зависимостями проектов, которые имеют сами проекты.Я не могу понять, как сделать это правильно.Например: 

-- Solution
----- Project A v1.0.6
----- Project B v1.0.1

Проект A (v1.0.6) зависит от проекта B (v1.0.1).Допустим, я изменяю Проект A (v1.0.7) и Проект B (v1.0.2) одновременно.У меня не может быть, чтобы Project A ссылался на пакет nuget Project B, так как он еще не собран, поэтому я использую Project References.Однако это приводит к тому, что пакет nuget пакета A (v1.0.7) предполагает, что он имеет тот же номер сборки, что и проект B (v1.0.2), - но это не так.Таким образом, когда кто-то использует проект A, ему говорят искать версию проекта B, которая не существует (в примере v1.0.7).Чтобы решить эту проблему, я добавил в Project A .csproj следующее: <ProjectReference Include="..\Company.ProjectB\Company.ProjectB.csproj" ExcludeAssets="All" />

Однако теперь потребитель не знает о зависимости Project B (так как он больше не отображается в зависимости от пакета Nuget) и когда они выяснят, что им это нужно, они получат ошибку времени выполнения при использовании проекта A, заявив, что он все еще ищет проект B v1.0.7, который, очевидно, не существует.

Как разумнообрабатывать ссылки на проекты при создании пакетов nuget без nuspec?Мне бы хотелось как можно меньше ручного вмешательства.

Мое другое решение - использовать ссылки на пакеты Nuget, но это означает, что Project B необходимо создать и развернуть, прежде чем разработчик сможет приступить к работе над Project A.

1 Ответ

0 голосов
/ 23 октября 2018

По своему дизайну, когда вы упаковываете проект, имеющий ссылки на проекты, эти зависимые проекты добавляются как зависимости NuGet, причем минимальная версия является текущей версией каждого проекта на момент упаковки.Чтобы понять почему, представьте, что вы внесли серьезное изменение в ProjectB и настроили ProjectA для работы с ним.Если вы публикуете ProjectA, но с зависимостью NuGet от старой версии ProjectB, пользователи NuGet ProjectA будут аварийно завершать работу во время выполнения, поскольку используемая ими версия ProjectB несовместима.NuGet не может знать об этом.

Поэтому, если вы хотите увеличить версию ProjectA, не увеличивая зависимую версию ProjectB, сделайте их в отдельных коммитах.В противном случае публикуйте новые версии ProjectA и ProjectB одновременно.

...