Я пытаюсь создать решение с отсутствующим содержимым packages (кроме repositories.config внутри) с помощью MSBuild 12.0. Я ожидаю, что он будет автоматически восстанавливать все недостающие пакеты перед сборкой, но это не так - MsBuild сообщает массу ошибок:
"вам не хватает директивы using или ссылки на сборку?"
NuGet Manager - 2,7 (я вижу это в Visual Studio 2013 около). Я даже пытался передать параметр EnableNuGetPackageRestore=true - не повезло. Что мне не хватает?
ОБНОВЛЕНО с последней официальной документацией NuGet по версии 3.3.0
NuGet предлагает три подхода к использованию восстановления пакетов.
Автоматическое восстановление пакетов - это рекомендованный командой NuGet подход к восстановлению пакетов в Visual Studio, и он был представлен в NuGet 2.7. Начиная с NuGet 2.7, расширение NuGet Visual Studio интегрируется в события сборки Visual Studio и восстанавливает недостающие пакеты при создании сборки. Эта функция включена по умолчанию, но разработчики могут отказаться от необходимости.
Вот как это работает:
- При сборке проекта или решения Visual Studio создает событие, которое сборка начинается в рамках решения.
- NuGet отвечает на это событие и проверяет файлы package.config, включенные в решение.
- Для каждого найденного файла пакета .config его пакеты перечислены и Проверено для существует в папке пакетов решений.
- Любые отсутствующие пакеты загружаются из настроенных пользователем (и включенных) источников пакетов, соблюдая порядок источников пакетов.
- Когда пакеты загружаются, они распаковываются в пакетов.
Если у вас установлен Nuget 2.7+; важно выбрать один метод для управления автоматическим восстановлением пакетов в Visual Studio.
Доступны два метода:
- (Nuget 2.7+): Visual Studio → Инструменты → Менеджер пакетов → Пакет Настройки менеджера → Включить автоматическое восстановление пакетов
- (Nuget 2.6 и ниже) Щелкните правой кнопкой мыши на решении и нажмите "Включить пакет". Восстановить для этого решения ".
Восстановление пакета командной строки требуется при построении решения из командной строки; он был представлен в ранних версиях NuGet, но был улучшен в NuGet 2.7.
nuget.exe restore contoso.sln
Восстановление пакета с интегрированным MSBuildподход - это первоначальная реализация восстановления пакета, и хотя это продолжает работать во многих сценариях, он не охватывает полный набор сценарии, рассмотренные двумя другими подходами.
Если вы используете Visual Studio 2017, которая поставляется с MSBuild 15, и ваши файлы .csproj имеют новый формат PackageReference, самый простой способ - использовать новую цель MSBuild Restore.
Никто на самом деле не ответил на первоначальный вопрос: "Как я могу получить пакеты NuGet для автоматического восстановления при сборке из командной строки с MSBuild?" Ответ таков: если вы не используете опцию "Включить восстановление пакета NuGet" (которая в настоящее время считается устаревшей согласно этой ссылке), вы не сможете (но см. Ниже). Если вы пытаетесь сделать, например, автоматические сборки на сервере CI, это отстой.
Однако есть немного окольный способ получить желаемое поведение:
nuget restore которое автоматически загрузит все недостающие пакеты.msbuild чтобы построить свое решение. Кроме того: хотя новый и рекомендуемый способ автоматического восстановления пакетов включает в себя меньше беспорядка в управлении версиями, он также делает невозможным восстановление пакета командной строки, если вы не перепрыгнете через лишний nuget.exe загрузки и запуска nuget.exe. Прогресс?
Автоматическое восстановление пакетов Nuget - это функция Visual Studio (начиная с 2013 года), а не MSBuild. Вам нужно будет запустить nuget.exe restore, если вы хотите восстановить пакеты из командной строки.
Вы также можете использовать функцию "Восстановить восстановление пакета Nuget", но это больше не рекомендуется пользователям nuget, потому что это навязывает изменения файлам проекта и может вызвать проблемы, если вы создадите эти проекты в другом решении.
Мне понадобилось время, чтобы выяснить всю картину, и я хотел бы поделиться ею.
В Visual Studio есть два подхода к использованию восстановления пакета: автоматическое восстановление пакетов и восстановление пакета MSBuild. Восстановление MSBuild-Integrated Restore восстанавливает пакеты во время процесса сборки, который может вызвать проблемы в некоторых сценариях. "Автоматическое восстановление пакетов" рекомендуемый подход команды NuGet.
Есть несколько шагов, чтобы сделать работу "Автоматическое восстановление пакетов":
В Visual Studio инструменты → Расширения и обновления, обновите NuGet, если есть более новая версия (версия 2.7 или новее)
Если вы используете TFS, в папке .nuget вашего решения удалите файлы NuGet.exe и NuGet.targes. Затем отредактируйте NuGet.Config, чтобы не проверять пакеты NuGet:
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
Если вы ранее отметили папку с пакетами решений в TFS, удалите папку и отметьте удаление удаления папки пакета.
Если вы не используете TFS, удалите папку .nuget.
В каждом файле проекта (.csproj или .vbproj) в вашем решении удалите строку, которая ссылается на файл NuGet.targets. Ссылка выглядит так:
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
Удалите эту строку в каждом файле проекта в своем решении.
В меню Visual Studio, либо через
Инструменты → Параметры → Менеджер пакетов → Общие или Инструменты → Диспетчер пакетов NuGet → Настройки диспетчера пакетов
включите следующие два параметра 1) "Разрешить NuGet загружать отсутствующие пакеты" 2) "Автоматическая проверка отсутствующих пакетов во время сборки в Visual Studio"
Проверьте конфигурацию восстановления вашего пакета с помощью следующих шагов
MSBuild 15 имеет параметр /t: restore, который делает это. поставляется с Visual Studio 2017.
Если вы хотите использовать это, вы также должны использовать новую PackageReference, что означает замену файла packages.config такими элементами (сделайте это в *.csproj):
<ItemGroup>
<!-- ... -->
<PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
<!-- ... -->
</ItemGroup>
Существует автоматическая миграция в этот формат, если вы щелкнете правой кнопкой мыши на "Ссылки" (он может не появиться, если вы только что открыли Visual Studio, пересоберите или откроете окно "Управление пакетами NuGet для решения", и оно начнет появляться).
У Иана Кемпа есть ответ (есть несколько пунктов кстати...), это просто добавить немного мяса к одному из его шагов.
Причина, по которой я оказался здесь, заключалась в том, что dev-машины строились нормально, но сервер сборки просто не сбрасывал требуемые пакеты (пустые папки с папками), и поэтому сборка была неудачной. Однако вход в сервер сборки и ручное создание рабочего процесса.
Чтобы выполнить второй шаг из 3-х шагов Ians (запуск восстановления nuget), вы можете создать цель MSBuild, запускающую команду exec, чтобы запустить команду восстановления nuget, как показано ниже (в этом случае nuget. exe находится в папке .nuget, а не на пути), который затем может быть запущен на этапе сборки TeamCity (другой доступный CI...) непосредственно перед созданием решения
<Target Name="BeforeBuild">
<Exec Command="..\.nuget\nuget restore ..\MySolution.sln"/>
</Target>
Для записи я уже пробовал тип бегуна "nuget installer", но этот шаг зависал на веб-проектах (работал для проектов DLL и Windows).
В проекте есть файл packages.config, содержащий сведения о пакете.
Также есть папка .nuget, которая содержит NuGet.exe и NuGet.targets. если какой-либо из файлов отсутствует, он не восстановит отсутствующий пакет и не приведет к "отсутствию директивы using или ссылки на сборку"? ошибка
Обратите внимание: если вы используете TeamCity в качестве сервера сборки, вы получаете шаг "NuGet Installer", который вы можете использовать для восстановления всех пакетов до этапа сборки.
Иногда это происходит, когда у вас есть папка пакета, который вы пытаетесь восстановить в папке "пакеты" (например, "Packages/EntityFramework.6.0.0/" ) , но "DLL" не находятся внутри нее (большинство систем управления версиями автоматически игнорируют файлы ".dll" ). Это происходит потому, что до того, как NuGet попытается восстановить каждый пакет, он проверяет, существуют ли уже существующие папки, поэтому, если он существует, NuGet предполагает, что внутри него находится "dll". Поэтому, если это проблема, просто удалите папку, в которой NuGet вернет ее правильно.
В Visual Studio 2017 - при компиляции с использованием IDE - он загрузит все недостающие пакеты nuget и сохранит в папке "пакеты".
Но на сборке сборки компиляция была выполнена с помощью msbuild.exe. В этом случае я загрузил nuget.exe и сохранил путь.
Во время каждого процесса сборки перед выполнением msbuild.exe. Он выполнит → nuget.exe restore NAME_OF_SLN_File (если есть только один.SLN файл, то вы можете игнорировать этот параметр)
У меня была проблема с пакетами nuget, которые не включались в скриптскую ночную сборку, которая строит sln файл с помощью devenv.exe.
Я последовал рекомендациям Microsoft, и ключевым шагом было обновление конфигурации NuGet в %AppData%/NuGet чтобы он содержал:
<configuration>
<packageRestore>
<add key="automatic" value="True" />
</packageRestore>
</configuration>
Вы также можете использовать
Update-Package -reinstall
восстановить пакеты NuGet на консоли управления пакетами в Visual Studio.