Подтвердить что ты не робот

'dotnet restore' против 'nuget restore' с TeamCity

У меня есть ASP.NET Core проект, который правильно собирается с Visual Studio, но он не собирается под MSBuild.

Он не находит все общие библиотеки (системные и т.д.).

Я использую TeamCity, и частью процесса сборки является nuget restore.

Я попытался сделать те же шаги, что и TeamCity, но вручную с помощью MSBuild, но не удалось найти библиотеки.

Я добавил dotnet restore и тогда он dotnet restore.

Итак, в чем разница между nuget restore dotnet restore?

4b9b3361

Ответ 1

И nuget restore dotnet restore примерно одинаковы: они выполняют операцию восстановления NuGet.

Единственное отличие: dotnet restore - это удобная оболочка для вызова dotnet msbuild/t:Restore которая вызывает восстановление, интегрированное в MSBuild. Это работает только в дистрибутивах MSBuild, которые включают NuGet, таких как Visual Studio 2017 (полный Visual Studio, инструменты сборки) или Mono 5. 2+ (=> msbuild/t:Restore) и .NET Core SDK, который предоставляет эту удобную команду,

На данный момент существует два способа использования пакетов NuGet в проектах (на самом деле три, но на данный момент давайте проигнорируем project.json в UWP):

  • packages.config: "классический" способ ссылки на пакеты NuGet. Это предполагает, что NuGet - это отдельный инструмент, а MSBuild ничего не знает о NuGet. Клиент NuGet, такой как nuget.exe или инструменты, интегрированные с Visual Studio, видит файл packages.config и загружает указанные пакеты в локальную папку при восстановлении. Установка пакета изменяет проект для ссылки на ресурсы из этой локальной папки. Таким образом, восстановление для проекта packages.config загружает только файлы.
  • PackageReference: проект содержит элементы MSBuild, которые ссылаются на пакет NuGet. В отличие от packages.config, перечислены только прямые зависимости, и файл проекта напрямую не ссылается на какие-либо ресурсы (файлы DLL, файлы содержимого) из пакетов. При восстановлении NuGet вычисляет граф зависимостей, оценивая прямые и транзитивные зависимости, следит за тем, чтобы все пакеты загружались в глобальный кэш пакетов пользователя (не для локального решения, поэтому он загружается только один раз), и записывает файл ресурсов в папку obj он содержит список всех пакетов и ресурсов, которые использует проект, а также дополнительные цели MSBuild, если какой-либо пакет содержит логику сборки, которую необходимо добавить в проект. Таким образом, восстановление NuGet может загружать пакеты, если их еще нет в глобальном кэше, и создавать этот файл ресурсов. В дополнение к ссылкам на пакеты, проект может также ссылаться на инструменты CLI, которые представляют собой пакеты NuGet, содержащие дополнительные команды, которые будут доступны для dotnet в каталоге проекта.

Интегрированное с msbuild восстановление работает только для проектов типа PackageReference (.NET Standard,.NET Core по умолчанию, но оно включено для любого проекта .NET), но не для проектов packages.config. Если вы используете новую версию nuget.exe (например, 4.3.0), он может восстановить оба типа проектов.

Ваша ошибка, связанная с отсутствующими типами, немного интереснее: "эталонные сборки" (библиотеки, которые передаются в качестве входных данных компилятору) не устанавливаются в системе, а поступают через пакеты NuGet. Поэтому до тех пор, пока пакеты NuGet отсутствуют в глобальном кэше пакетов или файл obj/project.assets.json не был сгенерирован операцией восстановления, фундаментальные типы, такие как System.Object, не будут доступны компилятору.

Ответ 2

У меня были похожие проблемы с проектом .NET Core 2, который прекрасно работал на моей рабочей станции - как в Visual Studio 2017, так и только с использованием MSBuild - но не встраивал TeamCity. Сообщение об ошибке было:

C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(327, 5):
Assets file 'D:\TeamCity\buildAgent\work\596486b1d4e7a8e7\Source\Integrations\SomeAPI\obj\project.assets.json' not found.
Run a NuGet package restore to generate this file.

В моей конфигурации сборки у меня уже был этап установки NuGet перед этапом сборки:

  • NuGetversion: 3.4.4
  • Режим восстановления: Установить

Оказалось, я должен был использовать:

  • Версия NuGet: 4.0.0 или выше
  • Режим восстановления: восстановление (требуется NuGet 2. 7+)

Ответ 3

nuget restore обеспечит загрузку всех ваших зависимостей NuGet и их доступность для вашего проекта. В то время как dotnet restore - это полное восстановление всех зависимостей NuGet, а также ссылок и инструментов, специфичных для проекта. Это означает, что если вы запускаете nuget restore, вы восстанавливаете только пакеты NuGet.

По данным docs.microsoft.com: восстановление Dotnet

Команда dotnet restore использует NuGet для восстановления зависимостей, а также специфичные для проекта инструменты, указанные в файле проекта...