Как обновить nuget в visual studio 2012

Обновлено: 07.07.2024

packages.config и PackageReference

Прежде чем перейти к рассмотрению каждого инструмента для управления пакетами, сделаем небольшое отступление. Видимо так исторически сложилось, что существует два формата хранения информации об установленных пакетах.

Package Manager UI и Package Manager Console

nuget.exe

Установка пакетов для заданного проекта
1. В папке проекта (где лежит файл *.csproj) создайте файл packages.config и добавьте в него информацию о необходимых пакетах. Вот пример такого файла:

<?xml version = "1.0" encoding = "utf-8" ?>
<packages >
<package id = "AForge" version = "2.2.5" targetFramework = "net46" />
<package id = "AForge.Imaging" version = "2.2.5" targetFramework = "net46" />
<package id = "AForge.Math" version = "2.2.5" targetFramework = "net46" />
</packages >

2. Далее в командной строке (обычной cmd.exe) запускаем nuget. При этом в аргументах командной строки обязательно надо указать путь к файлу packages.config и путь к папке, в которую будут установлены пакеты (обычно это папка packages, которая лежит в папке решения):

SolutionDir\ProjectDir> nuget install packages.config -OutputDirectory SolutionDir\packages

Восстановление пакетов для всего решения
Переходим в корневую папку решения и вызываем:

Когда нужно восстановить пакеты, nuget.exe ищет в папках проектов файлы packages.config и считывает из них информацию о том, какие именно пакеты надо установить.

dotnet.exe

Установка пакетов для заданного проекта

SolutionDir\ProjectDir> dotnet add package <PACKAGE_NAME> --package-directory <PACKAGE_DIRECTORY>

Восстановление пакетов для всего решения

SolutionDir> dotnet restore --packages <PACKAGES_DIRECTORY>

PowerShell PackageManagement

The commands listed here are specific to the Package Manager Console in Visual Studio, and differ from the Package Management module commands that are available in a general PowerShell environment.

И не видим ничего. А делать надо так:

Ага, есть такой пакет, называется Extended.Wpf.Toolkit. Теперь я его устанавливаю:

Естественно, никакие ссылки в проект не добавляются (т. е. в этом смысле PowerShell PackageManagement работает аналогично nuget.exe).
А теперь я хочу посмотреть список установленных пакетов:

Get - Package -Destination SolutionDir\packages
Name Version Source ProviderName
---- ------- ------ ------------
Extended.Wpf.Toolkit 3.5.0 SolutionDir\Extended.Wpf.Toolkit. NuGet

Переход с Nuget на Paket

При безусловных преимуществах, которые дает использование Nuget, есть и некоторые мелкие неудобства. Нас с коллегами например напрягало, что при установке (или восстановлении) пакета средствами Visual Studio в проект всегда добавляются ссылки на сборки пакета с установленным свойством Copy Local = True, т. е. они будут копироваться в выходную папку проекта, а нас такое поведение не устраивало по некоторым причинам.

1. Вам придется создать в корне вашего решения папку .paket, а поскольку имя папки начинается с точки, вы сможете сделать это только из командной строки:

2. Есть еще одна инструкция по установке, которая говорит: скачав файл paket.bootstrapper.exe в папку .paket, переименуйте его в paket.exe и закоммитьте (игнорировать его при помощи файла .gitignore, не надо). Зачем все это надо, написано в описании файла paket.bootstrapper.exe.

3. Для удобства пользования утилитой packet.exe существует расширение для Visual Studio под названием Paket for Visual Studio, которое обеспечивает некие плюшки, в частности подсветку синтаксиса и InteliSense для файлов paket.dependencies и paket.references. Но это расширение не устанавливается для Visual Studio 2019.

Установив paket.exe, подготавливаем наше решение (имеется в виду Visual Studio solution). Создаем в папке решения файл paket.dependencies. В нем перечисляются все пакеты для всех проектов решения, обычно, с указанием версий. Для одного из моих решений файл выглядит так:

// paket.dependencies file for paket package manager utility

// restrict target framework
framework: >= net46

// don't copy referenced assemblies to project's output directory
copy_local: false

// NuGet packages
nuget Accord 3.8.0
nuget Accord.Imaging 3.8.0
nuget Accord.MachineLearning 3.8.0
nuget Accord.Math 3.8.0
nuget Accord.Statistics 3.8.0
nuget Accord.Video 3.8.0
nuget Accord.Vision 3.8.0
nuget AForge 2.2.5
nuget AForge.Imaging 2.2.5
nuget AForge.Math 2.2.5
nuget AForge.Video 2.2.5
nuget AForge.Video.DirectShow 2.2.5
nuget AvalonEdit 5.0.4
nuget Extended.Wpf.Toolkit 2.5
nuget Mantin.Controls.Wpf.Notification 3.2.0.0
nuget MessagingToolkit.QRCode 1.3.0
nuget Microsoft.CodeDom.Providers.DotNetCompilerPlatform 2.0.1
nuget Ookii.Dialogs.Wpf 1.0.0
nuget System.ValueTuple 4.5.0
nuget System.Windows.Interactivity.WPF 2.0.20525

После того как файл paket.dependencies создан, можно попросить paket закачать пакеты:

Команда paket.exe install генерирует в папке решения файл paket.lock, который описывает какой пакет от какого пакета зависит. У меня он выглядит так:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform
System.ValueTuple

Если теперь запустить paket.exe install, то нужные пакеты не только загрузятся в папку packages (если они уже не загружены), но и в файл проекта (.csproj) добавятся ссылки на сборки из этих пакетов. Я уже писал выше, что для меня было важно в ссылках на сборки контролировать параметр Copy Local и делать его равным False. В paket это достигается строчкой copy_local: false в файле paket.dependencies.

Вот собственно и весь процесс использования paket. Последнее, что нужно сказать: если вы в своем решении уже пользовались NuGet, и переходите на paket, то утилита paket может выполнить этот переход полностью автоматически (т. е. вам не придется делать все, что было описано выше, нужно будет только скачать paket.exe):

Создание проектов и решений без Visual Studio

Создание файлов проектов и решений вручную

<Target Name = "PostBuild" AfterTargets = "Build" >

<Exec Command = "echo POSTBUILD COPYING OUTPUT FILES" />

<Copy SourceFiles = "@(OutputFiles)"
DestinationFolder = "$(DistributionFolder)" />
</Target >
</Project >

Во фрагменте файла проекта (.csproj) даны комментарии по терминологии (в MSBuild ключевую роль играют понятия: Target, Task, Property и Item). По принципам своей работы MSBuild очень похожа на утилиту make.

Небольшое отступление. Если речь не идет о создании нового файла проекта (.csproj), а лишь об изменении имеющегося, то даже необязательно редактировать файл проекта. Те изменения, которые вы планируете внести в файл проекта можно вынести в отдельные два файла Directory.Build.props и Directory.Build.targets, которые утилита MSBuild сама ищет в папке проекта и выше нее и импортирует в проект. Подробнее об этом читайте в статье Customize your build.

Утилита dotnet.exe

dotnet new sln -n MySolution
dotnet new classlib -n MyProject
dotnet sln MySolution.sln add MyProject/MyProject.csproj
dotnet build

Утилита CMake

Программная генерация файлов проектов и решений

Резюме

Сборка решения

MSBuild

SolutionDir> MSBuild.exe -property:Configuration=Release

Чтобы программа MSBuild успешно запустилась из командной строки, вам нужно либо добавить путь к папке, где лежит msbuild.exe в переменную окружения PATH (у меня это C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin ), либо запускать командную строку Visual Studio Command Prompt либо указывать полный путь к файлу MSBuild.exe.

Build Systems (автоматизация сборки решения)

Очистка решения и ⁄ или дистрибутива
Установка ⁄ восстановление ⁄ обновление пакетов
Построение проектов
Формирование дистрибутива (копирование всяких файлов в папку дистрибутива)

В итоге остановились на системе Nuke.

Установка Nuke на компьютер:

Установка Nuke в решение Visual Studio:

Далее у меня состоялся с утилитой следующий диалог:

How should the build project be named?
┐ nuke_build_project
Where should the build project be located?
┐ nuke_build_project
Which NUKE version should be used?
┐ 0.20.1 (latest release)
Which solution should be the default?
┐ MySuperBigSolution.sln
Do you need help getting started with a basic build?
┐ Yes, get me started!
Restore, compile, pack using .
┐ Neither
Source files are located in .
┐ ./src
Move packages to .
┐ Neither
Where do test projects go?
┐ ./tests
Do you use GitVersion?
┐ Yes, just not setup yet
Creating directory 'SolutionDir\nuke_build_project'.
Creating directory 'SolutionDir\tests'.

Пример очень простого кода Build.cs:

AbsolutePath SourceDirectory => RootDirectory / "src" ;

Итак, у нас есть проект программы, которая выполняет сборку решения. Теперь чтобы запустить процесс сборки решения, надо выполнить в командной строке powershell скрипт build.ps1:

SolutionDir> .\build.ps1 -target compile -configuration release

Расширения для Visual Studio

Command Task Runner

Вот пример файла commands.json с двумя задачами (BuildRelease и Clean), которые выполняются путем запуска скрипта build.ps1 (скрипт PowerShell, который появился при установке Nuke):

NUKE Support

Как пользоваться VS Code

Command Palette

Отладка в VS Code

В VS Code почему-то можно отлаживать только 64-разрядные программы, поэтому вам придется специально построить 64-разрядную версию своей программы. Для этого при компиляции вы должны передать утилите MSBuild параметр командной строки /p:Prefer32Bit=False . Если мы запускаем MSBuild из проекта nuke, то можно добавить такую tagret в исходный код проекта nuke:

Благодарности

Существует несколько ситуаций, описанных ниже в разделе Когда следует переустанавливать пакет, когда ссылки на пакет в проекте Visual Studio могут быть нарушены. В этих случаях удаление и повторная установка той же версии пакета восстанавливает работоспособность ссылок. Обновление пакета означает простую установку обновленной версии, что часто позволяет восстановить работоспособность пакета.

В Visual Studio консоль диспетчера пакетов позволяет обновлять и переустанавливать пакеты несколькими способами.

Обновление и переустановка пакетов выполняются следующим образом:

Метод	Update	Переустановка
Консоль диспетчера пакетов (описана в разделе Использование команды Update-Package)	Команда Update-Package	Команда Update-Package -reinstall
Пользовательский интерфейс диспетчера пакетов	На вкладке Обновления выберите один или несколько пакетов и затем элемент Обновить	На вкладке Установленные выберите пакет, запишите его имя, а затем выберите элемент Удалить. Перейдите на вкладку Обзор, найдите имя пакета, выберите его, а затем выберите элемент Установить.
Интерфейс командной строки nuget.exe	Команда nuget update	Для всех пакетов удалите папку пакета, а затем запустите nuget install . Для одного пакета удалите папку пакета, а затем используйте nuget install <id> для переустановки того же пакета.

Для интерфейса командной строки dotnet такая процедура не требуется. В аналогичном сценарии вы можете восстановить пакеты с помощью интерфейса командной строки dotnet.

Когда следует переустанавливать пакет

Нарушенные ссылки после восстановления пакета: если вы открыли проект и восстановили пакеты NuGet, но по-прежнему видите нарушенные ссылки, попробуйте переустановить каждый из этих пакетов.
Проект нарушен из-за удаленных файлов: NuGet не запрещает вам удалять элементы, добавленные из пакетов, поэтому вы легко можете случайно изменить содержимое, установленное из пакета, и нарушить работу проекта. Чтобы восстановить проект, переустановите затронутые пакеты.
Обновление пакета нарушило работу проекта. Если обновление пакета нарушает работу проекта, причиной сбоя обычно является пакет зависимостей, который также мог быть обновлен. Чтобы восстановить состояние зависимости, переустановите этот пакет.
Перенацеливание или обновление проекта: это может быть полезно, когда проект был перенацелен или обновлен и если он требует переустановки из-за изменения целевой платформы. В таких случаях NuGet выдает ошибку сборки сразу после перенацеливания проекта, а последующие предупреждения сборки сообщают, что для пакета может потребоваться переустановка. Для обновления проекта NuGet выводит ошибку в журнале обновления проекта.
Переустановка пакета во время его разработки: авторам пакетов часто требуется переустановить ту версию пакета, которую они разрабатывают, для тестирования поведения. Команда Install-Package не предоставляет возможность принудительной переустановки, поэтому используйте вместо нее Update-Package -reinstall .

Ограничение версий для обновления

По умолчанию для переустановки или обновлении пакета всегда устанавливается самая последняя доступная версия из источника пакета.

Однако в проектах, использующих формат управления packages.config , вы можете ограничить диапазон версий. Например, если известно, что приложение работает с версией 1.x пакета, но не работает с версией 2.0 и выше, возможно, из-за значительного изменения в API пакета, может потребоваться ограничить обновление версиями 1.x. Это предотвратит случайные обновления, приводящие к сбою приложения.

Чтобы задать ограничение, откройте packages.config в текстовом редакторе, найдите требуемую зависимость и добавьте атрибут allowedVersions с диапазоном версий. Например, чтобы ограничить обновления версией 1.x, задайте для allowedVersions значение [1,2) :

Во всех случаях используйте нотацию, описанную в статье Управление версиями пакета.

Использование команды Update-Package

Учитывая описанные ниже особенности, вы можете легко переустановить пакет с помощью команды Update-Package в консоли диспетчера пакетов Visual Studio (Средства > Диспетчер пакетов NuGet > Консоль диспетчера пакетов).

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

Та же команда без -reinstall обновляет пакет до более новой версии, если это возможно. Команда Update-Package выдает ошибку, если соответствующий пакет не установлен в проекте, то есть эта команда не устанавливает сами пакеты.

По умолчанию Update-Package затрагивает все проекты в решении. Чтобы ограничить действие конкретным проектом, используйте параметр -ProjectName , указав имя проекта в том виде, в котором оно отображается в обозревателе решений:

Чтобы обновить все пакеты в проекте (или переустановить с помощью -reinstall ), используйте -ProjectName без указания конкретного пакета:

Чтобы обновить все пакеты в решении, используйте только команду Update-Package без аргументов или параметров. Используйте эту форму осторожно, так как выполнение всех обновлений может занимать много времени:

При обновлении пакетов в проекте или решении с помощью PackageReference всегда применяется последняя версия пакета (кроме пакетов предварительного выпуска). Проекты, использующие packages.config , при необходимости могут ограничить версии обновления, как описано ниже в разделе Ограничение версий для обновления.

Дополнительные сведения о команде см. по ссылке Update-Package.

Рекомендации

Переустановка пакета может повлиять на следующее:

Переустановка пакетов в результате перенацеливания целевой платформы проекта

В простом случае можно выполнить переустановку пакета с помощью Update-Package –reinstall <package_name> . Пакет, установленный для старой целевой платформы, удаляется, после чего устанавливается тот же самый пакет для текущей целевой версии проекта.
В некоторых случаях пакет может не поддерживать новую целевую платформу.
- Если пакет поддерживает переносимые библиотеки классов (PCL), а проект перенацеливается на сочетание платформ, которое больше не поддерживается пакетом, после переустановки ссылки на этот пакет будут отсутствовать.
- Это может касаться пакетов, которые вы используете напрямую, или пакетов, установленных в качестве зависимостей. Используемый напрямую пакет может поддерживать новую целевую платформу, а его зависимость — нет.
- Если переустановка пакетов после перенацеливания приложения приводит к ошибкам сборки или времени выполнения, может потребоваться отменить изменение целевой платформы или найти альтернативные пакеты, должным образом поддерживающие новую целевую платформу.
Добавление атрибута requireReinstallation в файл packages.config после обновления или перенацеливания проекта
- Если NuGet обнаруживает, что пакеты были затронуты при перенацеливании или обновлении проекта, он добавляет атрибут requireReinstallation="true" в packages.config для всех затронутых ссылок на пакет. По этой причине каждая последующая сборка в Visual Studio вызывает предупреждения сборки для пакетов, чтобы вы не забыли переустановить их.
Переустановка пакетов с зависимостями
- Update-Package –reinstall переустанавливает ту же версию исходного пакета, но устанавливает последнюю версию зависимостей, если только не заданы определенные ограничения по версии. Это позволяет обновить только зависимости, чтобы устранить ошибку. Однако, если при этом зависимость откатывается до более ранней версии, можно использовать Update-Package <dependency_name> , чтобы переустановить эту отдельную зависимость, не затрагивая зависимый пакет.
- Update-Package –reinstall <packageName> -ignoreDependencies переустанавливает ту же версию исходного пакета, но не переустанавливает зависимости. Используйте эту команду, когда обновление зависимостей пакетов может привести к нарушению состояния.
Переустановка пакетов при использовании зависимых версий

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

В давние времена, когда компьютеры были уже персональными, но еще про .Net никто не слышал, стояла очень остро проблема, которая называлась DLL Hell. С появлением .Net и возможности непосредственно в сборке хранить информацию о версии, подписи и т.д. Проблема DLL Hell ушла в прошлое, GAC позволяет хранить в одном месте сборки разных версий. Но, следуя тем же рекомендациям от Micorosoft, если сборки не предполагаются для глобального использования, то лучше их размещать не в GAC, а тянуть вместе с приложением. Но в этом случае возникает проблема уже на стороне разработки. Как подключать эти "внешние" библиотеки в решения, как поддерживать их актуальную версию, особенно, если "внешние" библиотеки, являются действительно внешними по отношению к организации.
Для решения этой и многих других проблем, было разработано расширение для Visual Studio которое получило название NuGet.
NuGet позволяет добавлять, обновлять и удалять библиотеки в виде пакетов. NuGet-пакет является набором файлов, упакованных в один файл с расширением .nupkg.
NuGet, кстати позволяет не только подключать чужие пакеты, но и создавать свои, но об
этом в другой раз.
Давайте теперь покажу кучу картинок, как этим добром пользоваться.
В Visual Studio 2012 NugetManager уже установлен по умолчанию. Убедиться в этом модно открыв:

Как же им воспользоваться. Да нет ничего проще. Как я обещал в заголовке, пример будет на NuGet Package с именем NLog. Данный компонент служит, как следует из названия, для логирования, ну а зачем нужны логи я рассказывал на одном из собраний нашего MCP-клуба.
Все, к делу. Создаем новое консольное приложение и открываем контекстное меню на проекте:

Вполне закономерно выбрав Manage NuGet Packages увидим окно:

Оно пока пустое и скучное, т.к. мы в наш проект еще не подключили ни одного проекта. Подключаем, для этого выбираем в левом дереве Online, после чего в строку поиска вбиваем NLog. В загрузившемся списке выбираем сам NLog и файл конфигурации для него:

Инсталируем пакеты. Решение после инсталяции примет вид:

Все. Мы установили пакеты. Теперь, после построения, у нас в выходной папке будет не только наше решение, но и dll поставляемые в пакетах.
На этом про NuGet, я пока заканчиваю, а перехожу к NLog.
Для работы с NLog необходимо настроить файл конфигурации. На самом деле, в большинстве случаев, достаточно открыть его и раскоментировать два блока:

В соответствии с раскоментированными настройками, у нас появится вот такой файл:

Под управлением подразумевается поиск, скачивание, установка, настройка, обновление и удаление файлов сторонних разработчиков у себя в приложении.

Технически NuGet Manager представляет собой расширение для Visual Studio, доступное программисту в процессе работы над своим проектом. Если вы используете «студию» версии 2012 и выше, то NuGet уже заранее предустановлен и готов к работе. В случае версии 2010 его нужно установить вручную. Его можно скачать либо с официального сайта, либо установить напрямую из Visual Studio через менеджер дополнений.

Давайте откроем менеджер. Для этого в Solution Explorer щелкаем правой кнопкой мыши по рабочему проекту и в контекстном меню выбираем пункт «Manage NuGet Packages…»:

NuGet Manager открывается в новой вкладке в текстовом редакторе. Интерфейс у него довольно простой.

Три главные вкладки:
1. Browse. Найти и установить нужные нам пакеты из хранилища NuGet
2. Installed. Список уже установленных в нашем проекте библиотек
3. Updates. Библиотеки в нашем проекте, которые можно обновить до новой версии
Также в интерфейсе менеджера представлены:
1. Строка поиска. Мы можем искать нужную нам библиотеку, начав вводить ее название
2. Кнопка «Обновить состояние окна»
3. Галочка «Включать в выдачу предрелизные версии библиотек», например, какие-то тестовые или экспериментальные
4. Выпадающий список Package source. В каком месте менеджер будет искать нужные нам библиотеки
5. Кнопка «Настройки менеджера»
6. Главная панель с результатами выдачи (слева)
7. Панель с описанием того компонента, который мы выбрали (справа)
Попробуем установить какую-нибудь библиотеку к нам в проект, например, Entity Framework. Для этого переходим во вкладку Browse и в строке поиска начинаем вводить название нужного пакета. Далее выбираем его из списка и нажимаем кнопку Install. При необходимости можно выбрать определенную версию, отличную от стабильной последней, а также ознакомиться с информацией о данном пакете (авторы, лицензия и т.д.).

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

Теперь давайте более детально посмотрим, что конкретно сделал менеджер при установке этого компонента в наш проект:
1. Он определил, что для данного пакета нет никаких сторонних зависимостей. Если бы они были, то менеджер автоматически их определил и подтянул.
2. NuGet Manager добавил ссылку на установленный компонент в наш проект (References):

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

4. В конфигурационный файл packages.config была добавлена запись о новом пакете:

5. В конфигурационный файл приложения web.config также были внесены необходимые изменения, чтобы подготовить компонент Entity Framework к работе:

Вот такие операции происходят, когда NuGet Manager добавляет новую библиотеку к нам в проект.

Подобным образом происходит и обновление, и удаление компонентов из нашего проекта. В случае удаления менеджер также автоматически вносит изменения в файлы нашего проекта – убирает записи из файла packages.config, удаляет соответствующие файлы в папке packages, убирает ссылки на эти библиотеки.

Давайте рассмотрим еще несколько моментов.

С NuGet Manager можно работать не только через графический интерфейс, но и через командную строку (консоль). Чтобы ее открыть, идем Tools -> NuGet Package Manager -> Package Manager Console.

Работа в консоли ничем не отличается от работы в графическом интерфейсе, это дело вкуса.

Управление осуществляется посредством специальных команд. Чтобы вывести в консоль список всех доступных команд нужно написать инструкцию:

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

Добавляем пакет Entity Framework в текущий проект:

Обновляем ранее установленный пакет:

Переустанавливаем ВСЕ пакеты во всех проектах в данном решении:

Подведем краткий итог. NuGet – это просто незаменимый инструмент для разработчика на сегодняшний день. Он автоматизирует весь процесс работы с пакетами в проекте, а именно поиск, скачивание, установка, настройка, обновление и удаление файлов.

В видео версии этого урока более подробно и наглядно показана работа с этим инструментом.

У меня есть решение с несколькими проектами. Большинство сторонних ссылок отсутствует, но есть packages.config файл для каждого проекта. Как заставить NuGet установить / обновить все необходимые пакеты? Нужно ли это делать через командную строку для каждого проекта?

Вы можете использовать nuget.exe для восстановления ваших пакетов или с установленным NuGet 2.7 или выше, вы можете просто скомпилировать свое решение в Visual Studio, что также восстановит недостающие пакеты.

Для NuGet.exe вы можете выполнить следующую команду для каждого проекта.

Или с NuGet 2.7 вы можете восстановить все пакеты в решении с помощью командной строки.

Оба они снимут пакеты. Однако файлы вашего проекта не будут изменены при запуске этой команды, поэтому в проекте уже должна быть ссылка на пакеты NuGet. Если это не так, вы можете использовать Visual Studio для установки пакетов.

При использовании NuGet 2.7 и более поздних версий Visual Studio автоматически восстанавливает отсутствующие пакеты NuGet при создании решения, поэтому использовать NuGet.exe не нужно.

Чтобы обновить все пакеты в вашем решении, сначала восстановите их, а затем вы можете использовать NuGet.exe для обновления пакетов или из Visual Studio вы можете обновить пакеты из окна консоли диспетчера пакетов, или, наконец, вы можете использовать Управление Диалог пакетов.

Обратите внимание, что при этом не будут выполняться сценарии PowerShell в каких-либо пакетах NuGet.

Вы также можете ограничить это одним проектом.

Если вы хотите переустановить пакеты до тех же версий, которые были установлены ранее, вы можете использовать -reinstall аргумент с Update-Package команда.

Вы также можете ограничить это одним проектом.

В -reinstall вариант сначала удалит, а затем снова установит пакет в проект.

Или вы можете обновить пакеты с помощью Manage Packages диалог.

Обновления:

Переустановите все пакеты во ВСЕХ ПРОЕКТАХ текущего решения:

Переустановите все пакеты в КОНКРЕТНОМ ПРОЕКТЕ текущего решения (Благодаря единству и пеплу999):
- 63 Я думаю, что это действительно то, чего хотел ОП, и намного проще, чем все другие решения .
- 5 Это вариант ядерной бомбы, если вам просто нужно, чтобы он работал ПРЯМО СЕЙЧАС.
- 11 Это также идеальный вариант, если вы только что изменили целевую структуру или что-то подобное. Я столкнулся с перспективой обновления 25 с лишним проектов с множеством распределенных вокруг них пакетов nuget, и первая команда идеально подходила для того, что я хотел. И даже не ядерное оружие в смысле излишнего уничтожения.
- 7 Это должен быть ответ на этот вопрос, принятый ответ действительно работает, но он конкретно отвечает на вопрос. +1 за то, что было именно то, что нужно.
- 10 Возможно, вы даже захотите добавить переключатель -IgnoreDependencies. У меня произошел сбой Update-Package, потому что зависимость одного из пакетов, которые я использовал, существовала в более новой версии, чем указано в моих файлах packages.config
Есть еще один, более новый и быстрый способ сделать это из Visual Studio. Прочтите этот пост Дэвида Эббо и обратитесь к разделу комментариев, если у вас возникнут проблемы. Обычно в приглашении диспетчера пакетов вы делаете следующее:

Впоследствии, когда вы создадите свое решение, пакеты будут автоматически установлены, если они отсутствуют.

Обновить:

Эта функция встроена в Nuget 1.6 с интеграцией с визуальной студией, поэтому вам даже не нужно устанавливать NuGetPowerTools или вводить команды. Все, что тебе нужно сделать, это

Прочтите эту статью для получения более подробной информации.
- 6 Обновленный ответ здесь будет лучшим решением для большинства людей, так как у них не будет nuget.exe (но Nuget будет установлен в Visual Studio).
- 1 Но восстановление пакета фактически загружает nuget.exe для вас
- 4 Я только что сделал это. и он по-прежнему не выполняет сборку, говоря, что ссылки отсутствуют. Build говорит, что все пакеты уже установлены. Я зашел в папку solution / packages, удалил нужные пакеты, они загрузились и начали работать.
- 4 @Shy этот способ теперь не рекомендуется в пользу решения, которое не изменяет все файлы вашего проекта.
Вот еще одно решение, если вы используете проекты веб-сайтов или не хотите включать восстановление пакета NuGet.

Вы можете использовать консоль диспетчера пакетов, чтобы перечислить все пакеты в файле package.config и переустановить их.

Это лучший и самый простой пример, который я нашел. Он переустановит все nugets, перечисленные в packages.config, и сохранит текущие версии. Заменить YourProjectNameGoesHere с названием проекта.

Я использую Visual Studio 2015, и приведенные выше решения у меня не работали, поэтому я сделал следующее:

Удалите папку пакетов из моего решения, а также папки bin и obj из каждого проекта в решении и выполните перестройку.

Может у вас будет следующая ошибка:

Чтобы решить эту проблему: измените эту строку в файле NuGet.targets и установите для нее значение true:

Если вы устанавливаете Nuget 2.8, установите флажок

в Visual Studio. Если он отмечен, то просто перестройте проект, чтобы восстановить все ваши справочные библиотеки.
- Самый удобный вариант из UI Visual Studio. Вам также необходимо проверить Allow NuGet to download missing packages также флажок.
После 3 часов поиска и расследования.

У меня были проблемы с этим, потому что у нас есть два члена в команде (с использованием системы управления версиями GitHub), потому что мы не ограничивали файлы для пакетов для отправки в удаленный репозиторий, один из членов команды отправлял пакеты на сервер, и я получил эти изменения в мой местный.

После этого у меня возникла та же проблема, что и у PO, также я не смог опубликовать свой проект API на сервере.

В и я только что использовал

Обновление-Пакет -Переустановить - запустите эту команду в консоли диспетчера пакетов

Эта команда переустановит все ваши пакеты, которые вы использовали в своем решении. (Для каждого проекта)

Переустановите все пакеты во ВСЕХ ПРОЕКТАХ текущего решения:

Эта команда переустановит все ваши пакеты, связанные с проектом, который вы указали после "-ProjectName". И я думаю, что это лучше, потому что мне пришлось ждать полчаса, чтобы переустановить все пакеты в решении.

За это большое спасибо Родольфо Броку.

Я считаю, что первое, что вам нужно сделать, это включить функцию восстановления пакета. Смотрите также здесь. Это делается на уровне решения (а не проекта).

Но это не поможет вам полностью - я столкнулся с аналогичной проблемой после включения функции восстановления. (VS2013, NuGet 2.8.)

Оказалось, что я (непреднамеренно) передал пакеты в систему управления версиями, когда зафиксировал проект - но Visual Studio (и подключаемый модуль системы управления версиями) услужливо проигнорировали двоичные файлы при выполнении проверки.

Проблема возникла, когда я создал ветку релиза. В моей локальной копии ветки dev / main / trunk были двоичные файлы, потому что я изначально установил / загрузил пакеты.
Однако в новой ветке выпуска
- папки пакета и .nupkg все файлы были там, поэтому NuGet не думал, что есть что восстанавливать;
- но в то же время не было ни одной из DLL - т.е. отсутствовали сторонние ссылки - поэтому я не мог собрать.
Я удалил все папки пакетов в $(SolutionDir)/packages (в ветке выпуска), а затем выполнил полную перестройку, и на этот раз сборка прошла успешно.
. а затем, конечно, я вернулся и удалил папки пакетов из системы управления версиями (в ветке ствола и выпуска). Я не уверен (пока) в том, repositories.config файл также следует удалить.

Многие из компонентов, устанавливаемых для вас шаблонами проектов - по крайней мере, для веб-проектов - являются пакетами NuGet. То есть эта проблема не ограничивается добавленными вами пакетами.
Поэтому включите восстановление пакета сразу после создания проекта / решения и перед выполнением начальной регистрации снимите флажок packages папку (и убедитесь, что вы зафиксировали .nuget папку в систему управления версиями).

Отказ от ответственности: я видел здесь еще один ответ на SO, который указывал, что очистка packages папка была частью разрешения. Это поставило меня на правильный путь, поэтому я хотел бы отдать должное автору, но я больше не могу найти этот вопрос / ответ. Я опубликую правку, если наткнусь на нее.

Также отмечу, что Update-Package -reinstall изменит .sln и .csproj / .vbproj файлы. По крайней мере, так было в моем случае. Что ИМХО делает этот вариант менее привлекательным.
- У меня была такая же проблема, и я потратил много времени на обновление и переустановку пакетов, когда, как вы говорите, все, что нужно было сделать, это удалить локальные пакеты.
Для тех, кто прибыл сюда из-за того, что сервер сборки не справился с этим, вы можете создать цель MSBuild, запустив команду exec для запуска nuget восстановить команда, как показано ниже (в этом случае nuget.exe находится в папке .nuget, а не на пути), которую затем можно запустить на этапе сборки TeamCity непосредственно перед сборкой решения.

Я старался Update-Package -reinstall но он не работает с пакетом и перестает обрабатывать все оставшиеся пакеты проектов в моем решении.

Я закончил свой скрипт, который перечисляет все файлы package.config и запускает Update-Package -Reinstall -ProjectName prj -Id pkg для каждого проекта / пакета.

Надеюсь, это может быть полезно для кого-то:

Редактировать: Это ошибка, которая у меня была: Пакет обновления: не удалось найти пакет EntityFramework.BulkInsert-ef6. Перед установкой или обновлением необходимо восстановить существующие пакеты. Ручной запуск Update-Package -Reinstall -ProjectName my_prj -Id EntityFramework.BulkInsert-ef6 работал очень хорошо.
- Я тоже плачу от радости! Да!! Какая экономия времени. Как и в случае с FYI, если вы используете эту строку вместо последней строки в скрипте Сергея, зависимости не будут установлены. Просто переустановка: $ projectPackages | foreach
Поэтому я просто использовал:

РЕДАКТИРОВАТЬ 2014-09-25 10:55 AM EST - Исправлена ошибка в скрипте

Читайте также: