Изменение ссылки проекта на ссылку пакета NuGet при сборке - PullRequest
0 голосов
/ 25 февраля 2019

У меня есть решение Visual Studio с двумя проектами: библиотека .NET Standard (2.0), содержащая некоторую логику, и библиотека классов .NET Framework (4.6.1), содержащая пользовательский интерфейс и т. Д. В библиотеке .NET Framework есть.Библиотека NET Standard добавлена ​​в качестве ссылки на проект, поэтому она может использовать методы, содержащиеся в библиотеке логики.

Затем я использую конвейеры Azure в DevOps Azure, чтобы построить эти два проекта, упаковать их в пакеты NuGet и отправить их вСервер NuGet, предоставленный Azure Devops (артефакты Azure).

Однако, когда пакеты NuGet публикуются, они включают в себя зависимости в NuGet только от пакетов, которые я добавил в проекты через NuGet.В идеале я хочу, чтобы моя библиотека .NET Standard (logic) была упакована и отправлена ​​на сервер NuGet, а ссылка на нее в NuGet (с обновленным номером версии и т. Д.) Добавлена ​​в мою библиотеку .NET Framework (UI).

Кто-нибудь еще имел эту проблему, которая может дать мне несколько советов о том, как ее решить, пожалуйста?Я посмотрел онлайн и нарисовал бланк.

Спасибо!

Ответы [ 3 ]

0 голосов
/ 26 февраля 2019

Изменение ссылки проекта на ссылку пакета NuGet при сборке

Боюсь, вы не смогли преобразовать ссылку проекта в ссылку на пакет nuget во время сборки.Это потому, что это два разных способа обращения со ссылками.Хотя в настоящее время есть некоторые расширения, которые могут преобразовывать ссылку проекта в ссылку на пакет nuget, они требуют ручного управления, но мы не можем использовать его во время сборки.

Проверьте другой поток для некоторыхбольше деталей.

Таким образом, мы не можем изменить ссылку проекта .NET Standard (2.0) library на ссылку пакета NuGet и добавить ее в вашу библиотеку .NET Framework (UI) в build .

ЛичноЧтобы решить эту проблему, вы можете использовать ссылку на проект .net Standard (.netSrd) в качестве ссылки на пакет nuget на локальном компьютере. Когда вы обновили пакет nuget с номером версии для проекта .net Standard, вы можете обновить этот пакет в артефактах Azure.и используйте настраиваемую команду задачи nuget для вызова команды nuget update , чтобы обновить пакеты до последней версии при сборке библиотеки .NET Framework (UI).

Проверьте подробную информацию из:

Обновление пакета NuGet до последней версии после сборки в VSTS

Надеюсь, это поможет.

0 голосов
/ 26 февраля 2019

Мой ответ состоит из двух частей.

Во-первых, если вы используете dotnet pack или msbuild -t:pack без файла nuspec, тогда ссылки на проекты автоматически становятся зависимостями nuget.Я проверил это с помощью следующих команд:

dotnet new classlib -n ProjectA
dotnet new classlib -n ProjectB
dotnet add ProjectB/ProjectB.csproj reference ProjectA/ProjectA.csproj
dotnet pack ProjectB/ProjectB.csproj

ProjectB.1.0.0.nupkg имеет зависимость nuget от ProjectA v1.0.0.Это работает "из коробки" с проектами в стиле SDK, но если у вас есть проект "старого стиля" (который импортирует Microsoft.CSharp.targets), вам нужно добавить ссылку на пакет в NuGet.Build.Tasks.Pack,Если вы используете PackageReference, вам может потребоваться отредактировать ваш csproj и установить эту зависимость, чтобы установить PrivateAssets для всех, чтобы этот пакет не становился зависимостью nuget.Я не знаю, что эквивалентно, если вы используете package.config, или если это вообще возможно.Если вы используете msbuild или dotnet pack, но у вас также есть свой собственный файл nuspec, я рекомендую против этого.Все, что вы хотите сделать в nuspec, должно быть возможным путем установки правильных свойств или атрибутов элементов в вашем csproj, и позволить целям пакета автоматически генерировать nuspec.Когда у вас есть собственный nuspec, части автогенерации nuget отключаются, поэтому вам может быть все сложнее для себя.

Моя память о nuget pack в файлах csproj старого стиля такова, что nuget автоматическипроект ссылается на зависимость nuget, если у указанного проекта есть файл <project name>.nuspec в том же каталоге, что и файл <project name>.csproj (я почти уверен, что он задокументирован где-то на docs.microsoft.com/nuget).Однако, если ваш зависимый проект представляет собой проект в стиле SDK (как это необходимо для проектов .NET Core или .NET Standard), тогда я уже советовал не использовать файл nuspec с этими проектами, поэтому вам следует рассмотреть возможность использования целей пакета и прекратить работу.использование nuget pack.

Во второй части моего ответа будет дан прямой ответ на ваш вопрос о том, как сделать ссылку на проект ссылкой на пакет в определенных сборках.Во-первых, вам нужно использовать цели пакета либо с помощью проекта в стиле SDK, либо с помощью ссылки на пакет NuGet.Build.Tasks.Pack.Таким образом, вы не используете файл nuspec, и все определено в вашем csproj, который является просто файлом MSBuild.В MSBuild есть условия, поэтому отредактируйте вручную ваш csproj и сделайте так, чтобы ссылка на проект имела определенное условие, а ссылка на пакет - на противоположное условие.Я предлагаю использовать такую ​​переменную, как $ (CI), чтобы вы могли протестировать пакет, используя msbuild -t:pack -p:CI=true, и на своей машине CI просто установите для CI в качестве переменной среды значение true.Поскольку в NuGet уже есть встроенная функциональность для преобразования ссылок проекта в зависимости nuget, я рекомендую использовать это, а не переключаться между ссылками на пакеты и проекты, поэтому я не собираюсь приводить пример копирования-вставки, как это сделать.Но если это не проблема XY и вам действительно нужно это сделать, то я уже дал достаточно указателей, чтобы вы могли понять, как делать все остальное.

0 голосов
/ 25 февраля 2019

NuGet CLI имеет проблемы с зависимостями для PackageReferences и ссылками на проект (только если проект является .net Core или .net Standard тоже?), Когда не используются файлы .nuspec.

Используйте dotnet pack или msbuild -t:pack, чтобы включить ссылку на проект в качестве зависимости nuget.Это также решает проблемы, связанные с тем, что PackageReferences не записываются как зависимости.

Предполагая, что ваш .NET Framework является готовым к использованию из Visual Studio, вам необходимо сослаться на Nuget.Build.Tasks.Pack пакет nuget для доступа к необходимым целям.Мы записываем эти данные в файл .csproj с powershell на сервере сборки перед любым восстановлением nuget, чтобы не забыть о новых проектах с полной структурой (которые мы пытаемся избежать).Как уже упоминалось @zivkan, вы, вероятно, захотите

установить для PrivateAssets значение all, чтобы этот пакет не стал зависимым от nuget

<PackageReference Include="NuGet.Build.Tasks.Pack">
  <PrivateAssets>all</PrivateAssets>
  <Version>4.8.0</Version>
</PackageReference>
...