Что такое nuget в visual studio
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
[!Note] If you are using Visual Studio for Mac, refer to this information on creating a NuGet package, or use the dotnet CLI tools.
If it's not already installed, install the dotnet CLI.
Create a class library project
Right-click on the resulting project file and select Build to make sure the project was created properly. The DLL is found within the Debug folder (or Release if you build that configuration instead).
Within a real NuGet package, of course, you implement many useful features with which others can build applications. For this walkthrough, however, you won't write any additional code because a class library from the template is sufficient to create a package. Still, if you'd like some functional code for the package, use the following:
Configure package properties
Right-click the project in Solution Explorer, and choose Properties menu command, then select the Package tab.
[!Note] For packages built for public consumption, pay special attention to the Tags property, as tags help others find your package and understand what it does.
Give your package a unique identifier and fill out any other desired properties. For a mapping of MSBuild properties (SDK-style project) to properties in a .nuspec, see pack targets. For descriptions of properties, see the .nuspec file reference. All of the properties here go into the .nuspec manifest that Visual Studio creates for the project.
[!Important] You must give the package an identifier that's unique across nuget.org or whatever host you're using. For this walkthrough we recommend including "Sample" or "Test" in the name as the later publishing step does make the package publicly visible (though it's unlikely anyone will actually use it).
If you attempt to publish a package with a name that already exists, you see an error.
(Optional) To see the properties directly in the project file, right-click the project in Solution Explorer and select Edit AppLogger.csproj.
This option is only available starting in Visual Studio 2017 for projects that use the SDK-style attribute. Otherwise, right-click the project and choose Unload Project. Then right-click the unloaded project and choose Edit AppLogger.csproj.
Run the pack command
Set the configuration to Release.
Right click the project in Solution Explorer and select the Pack command:
1>------ Build started: Project: AppLogger, Configuration: Release Any CPU ------ 1>AppLogger -> d:\proj\AppLogger\AppLogger\bin\Release\netstandard2.0\AppLogger.dll 1>Successfully created package 'd:\proj\AppLogger\AppLogger\bin\Release\AppLogger.1.0.0.nupkg'. ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
(Optional) Generate package on build
You can configure Visual Studio to automatically generate the NuGet package when you build the project.
In Solution Explorer, right-click the project and choose Properties.
In the Package tab, select Generate NuGet package on build.
[!NOTE] When you automatically generate the package, the time to pack increases the build time for your project.
(Optional) pack with MSBuild
As an alternate to using the Pack menu command, NuGet 4.x+ and MSBuild 15.1+ supports a pack target when the project contains the necessary package data. Open a command prompt, navigate to your project folder and run the following command. (You typically want to start the "Developer Command Prompt for Visual Studio" from the Start menu, as it will be configured with all the necessary paths for MSBuild.)
Publish the package
Acquire your API key
Publish with the dotnet CLI or nuget.exe CLI
This step is the recommended alternative to using nuget.exe .
Before you can publish the package, you must first open a command line.
This step is an alternative to using dotnet.exe .
Open a command line and change to the folder containing the .nupkg file.
Run the following command, specifying your package name (unique package ID) and replacing the key value with your API key:
nuget.exe displays the results of the publishing process:
Manage the published package
Adding a readme and other files
To directly specify files to include in the package, edit the project file and use the content property:
This will include a file named readme.txt in the package root. Visual Studio displays the contents of that file as plain text immediately after installing the package directly. (Readme files are not displayed for packages installed as dependencies). For example, here's how the readme for the HtmlAgilityPack package appears:
[!Note] Merely adding the readme.txt at the project root will not result in it being included in the resulting package.
Создание пакета NuGet
Пакет NuGet можно создать двумя способами. Новый и рекомендуемый способ — создать пакет из проекта в стиле пакета SDK (файл проекта, содержимое которого начинается с ). Сборки и целевые объекты автоматически добавляются в пакет, а метаданные, например имя пакета и номер версии, — в файл MSBuild. Компиляция с помощью команды dotnet pack создает файл *.nupkg , а не сборки.
Более старый способ создания пакета NuGet — это файл *.nuspec и средство командной строки nuget.exe . Файл с расширением .nuspec предоставляет функции управления, но указывать сборки и целевые объекты для включения в пакет NuGet нужно внимательно. Здесь очень легко допустить ошибку или забыть обновить файл .nuspec после внесения изменений. преимущество nuspec заключается в том, что его можно использовать для создания пакетов NuGet для платформ, которые еще не поддерживают файл проекта в стиле пакета SDK.
✔ РЕКОМЕНДУЕТСЯ использовать файл проекта в стиле SDK для создания пакета NuGet.
Зависимости пакетов
Важные метаданные пакета NuGet
Проект без лицензии по умолчанию получает статус монопольного авторского права, то есть не может законно использоваться другими пользователями.
✔ РЕКОМЕНДУЕТСЯ выбрать имя пакета NuGet с префиксом, который соответствует критериям для резервирования префикса NuGet.
✔️ СЛЕДУЕТ использовать для значка пакета изображение размером 64 × 64 с прозрачным фоном, чтобы обеспечить оптимальную видимость.
✔ РЕКОМЕНДУЕТСЯ настроить Source Link, чтобы добавить метаданные системы управления версиями в сборки и пакет NuGet.
Source Link автоматически добавляет метаданные RepositoryUrl и RepositoryType в пакет NuGet. Source Link также добавляет сведения о точном исходном коде, из которого создан пакет. Например, к пакету, созданному из репозитория Git, будет добавлен хэш фиксации в качестве метаданных.
Пакеты предварительного выпуска
Пакеты NuGet с суффиксом версии получают статус предварительной версии. По умолчанию в пользовательском интерфейсе диспетчера пакетов NuGet отображаются только стабильные выпуски, если пользователь не согласился использовать пакеты предварительной версии. Благодаря такой политике пакеты предварительной версии предоставляются для тестирования ограниченному числу пользователей.
В пакетах стабильных выпусков нельзя указывать зависимости от пакетов предварительной версии. В таком случае переведите используемый пакет в режим предварительной версии или укажите зависимость от более ранней стабильной версии.
✔️ СЛЕДУЕТ опубликовать пакет в режиме предварительной версии для тестирования, предварительного просмотра или экспериментов.
✔️ опубликовать стабильный пакет, когда он готов, чтобы другие стабильные пакеты могли ссылаться на него.
Пакеты символов
сервер символов NuGet. org поддерживает только новые переносимые файлы символов ( ), созданные в проектах в стиле пакета SDK.
Ключевой инструмент для любой современной платформы разработки — это механизм, с помощью которого разработчики могут создавать, передавать друг другу и использовать полезный код. Часто такой код распределен по "пакетам", включающим скомпилированный код (в виде библиотек DLL) и другое содержимое, необходимое использующим эти пакеты проектам.
Проще говоря, пакет NuGet представляет собой отдельный ZIP-файл с расширением .nupkg , который содержит скомпилированный код (DLL), другие файлы, связанные с этим кодом, и описательный манифест, включающий такие сведения, как номер версии пакета. Разработчики, у которых есть код, к которому нужно предоставить общий доступ, создают пакеты и публикуют их на закрытых или открытых узлах. Потребители получают эти пакеты из соответствующих узлов, добавляют их в свои проекты, а затем вызывают функции пакета в коде своего проекта. При этом NuGet сам обрабатывает все промежуточные данные.
Поток пакетов между создателями, узлами и потребителями
Независимо от своей природы, узел выступает в качестве точки подключения между создателями и потребителями пакета. Создатели разрабатывают полезные пакеты NuGet и публикуют их на узле. Потребители ищут полезные и совместимые пакеты на доступных узлах, скачивая эти пакеты и включая их в свои проекты. После установки в проекте API пакеты становятся доступны остальной части кода проекта.
Совместимость пакета с разными целевыми платформами
Средства NuGet
Кроме поддержки размещения, NuGet также предоставляет широкий набор средств, используемых как создателями, так и потребителями. Сведения о получении конкретных средств см. в разделе Установка клиентских средств NuGet.
Как видите, средства NuGet, с которыми вы работаете, в значительной степени зависят от того, создаете, потребляете или публикуете вы пакеты, а также от используемой платформы. Создатели пакета обычно также являются потребителями, так как берут за основу функции, имеющиеся в других пакетах NuGet. Конечно же, те пакеты, в свою очередь, могут зависеть еще от каких-либо.
Управление зависимостями
Возможность легко брать за основу работу других — это одна из наиболее мощных функций системы управления пакетами. Соответственно, значительная часть работы NuGet заключается в управлении этим деревом или "схемой" зависимостей от имени проекта. Проще говоря, вам нужно заботиться только о тех пакетах, которые вы используете непосредственно в проекте. Если эти пакеты используют другие пакеты (которые, в свою очередь, также используют пакеты), все эти зависимости нижнего уровня обрабатывает NuGet.
На следующем рисунке показан проект, зависящий от пяти пакетов, которые, в свою очередь, зависят от нескольких других.
Обратите внимание, что некоторые пакеты встречаются на графе зависимостей несколько раз. Например, существует три разных потребителя пакета B, и каждый из них может также указывать другую версию этого пакета (не показано). Это обычное дело, особенно для широко используемых пакетов. NuGet выполняет всю работу, чтобы определить, какая именно версия пакета B отвечает потребностям всех потребителей. Затем NuGet делает то же самое для всех других пакетов, независимо от того, насколько глубока схема зависимостей.
Дополнительные сведения о том, как NuGet выполняет эту задачу, см. в разделе Разрешение зависимостей.
Отслеживание ссылок и восстановление пакетов
Так как проекты можно легко перемещать между компьютерами разработчиков, репозиториями управления исходным кодом, серверами сборки и т. д., крайне непрактично хранить двоичные сборки из пакетов NuGet напрямую привязанными к проекту. В этом случае каждая копия проекта будет излишне раздутой (и, следовательно, расходовать пространство в репозиториях системы управления исходным кодом). Кроме того, обновить двоичные файлы пакета до новой версии будет очень сложно, так как обновление будет применяться ко всем копиям проекта.
Вместо этого NuGet поддерживает простой список ссылок на пакеты, от которых зависит проект, включая зависимости верхнего и нижнего уровня. То есть при установке пакета с некоторого узла в проект NuGet записывает идентификатор пакета и номер версии в этот список ссылок. (При удалении пакет, конечно же, убирается из этого списка.) Затем в NuGet можно восстановить все связанные пакеты по запросу, как описано в статье о восстановлении пакета.
С помощью только списка ссылок NuGet затем может переустановить (то есть восстановить) все эти пакеты из общедоступных и (или) частных узлов в любое время. При фиксации проекта в системе управления исходным кодом или предоставления его для общего доступа каким-либо иным образом нужно включить только список ссылок и исключить какие-либо двоичные файлы пакета (см. раздел Пропуск пакетов NuGet в системах управления исходным кодом.)
Компьютер, принимающий проект, например сервер сборки, получающий копию проекта в рамках работы системы автоматического развертывания, просто запрашивает у NuGet восстановление зависимости всякий раз, когда они понадобятся. Системы сборки, такие как Azure DevOps, предоставляют шаги "Восстановление NuGet" именно для этой цели. Аналогично, когда разработчики получают копию проекта (например, при клонировании репозитория), они могут вызвать такие команды, как nuget restore (CLI NuGet), dotnet restore (CLI dotnet) или Install-Package (консоль диспетчера пакетов), чтобы получить все необходимые пакеты. Visual Studio, со своей стороны, автоматически восстанавливает пакеты при создании проекта (при условии, что включено автоматическое восстановление, как описано в статье Восстановление пакетов).
Очевидно, что основная роль NuGet, связанная с разработчиками, заключается в обслуживании этого списка ссылок от имени проекта и предоставлении средств для эффективного восстановления (и обновления) таких указанных в ссылках пакетов. Этот список хранится в одном из двух указанных ниже форматов управления пакетами:
packages.config : (NuGet 1.0+) XML-файл, содержащий неструктурированный список всех зависимостей в проекте, включая зависимости других установленных пакетов. Установленные или восстановленные пакеты хранятся в папке packages .
Применение конкретного формата управления пакетами зависит от типа проекта и доступной версии Visual Studio и NuGet. Чтобы проверить, какой формат используется, просто найдите packages.config в корневом каталоге проекта после установки первого пакета. Если этот файл отсутствует, найдите в файле проекта элемент .
При наличии возможности выбора рекомендуем использовать PackageReference. Файл packages.config используется в устаревших версиях и больше не применяется в активной разработке.
Различные команды интерфейса командной строки nuget.exe , например nuget install , не добавляют автоматически пакет в список ссылок. Этот список обновляется при установке пакета с помощью диспетчера пакетов Visual Studio (пользовательского интерфейса или консоли) и интерфейса командной строки dotnet.exe .
Что еще делает NuGet?
Мы уже выучили следующие характеристики NuGet:
Чтобы обеспечить эффективную работу этих процессов, NuGet осуществляет некоторые оптимизации в фоновом режиме. В частности, NuGet управляет кэшем пакета и папкой глобальных пакетов, что позволяет упростить установку и повторною установку. Кэш позволяет избежать загрузки пакета, который уже установлен на компьютере. Папка глобальных пакетов позволяет в нескольких проектах совместно использовать один установленный пакет, тем самым уменьшая общий размер пакетов NuGet на компьютере. Это очень удобно, когда вы часто восстанавливаете большее количество пакетов, например, как на сервере сборки. Дополнительные сведения об этих механизмах см. в статье Управление папкой установки глобальных пакетов, кэшем и временными папками.
Кроме того, NuGet обслуживает все спецификации, связанные со структурированием пакетов (включая локализацию и отладочные символы) и ссылками на них (включая диапазоны версий и предварительные версии). NuGet также имеет различные API для работы со своими службами программно и предоставляет поддержку разработчикам, которые пишут расширения Visual Studio и шаблоны проектов.
Если изучить содержание этой документации, можно найти все указанные возможности и заметки о выпуске, отсылающие к самому начальному этапу развития NuGet.
Связанные видео
Другие видео о NuGet см. на Channel 9 и YouTube.
Комментарии, вклады и проблемы
Наконец, мы очень рады комментариям и вкладам в эту документацию— просто выберите команды "Отзывы" и "Изменить" в верхней части любой страницы или посетите репозиторий документов и список проблем с документацией по GitHub.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Введение в NuGet
Ключевой инструмент для любой современной платформы разработки — это механизм, с помощью которого разработчики могут создавать, передавать друг другу и использовать полезный код. Часто такой код распределен по "пакетам", включающим скомпилированный код (в виде библиотек DLL) и другое содержимое, необходимое использующим эти пакеты проектам.
Проще говоря, пакет NuGet представляет собой отдельный ZIP-файл с расширением .nupkg , который содержит скомпилированный код (DLL), другие файлы, связанные с этим кодом, и описательный манифест, включающий такие сведения, как номер версии пакета. Разработчики, у которых есть код, к которому нужно предоставить общий доступ, создают пакеты и публикуют их на закрытых или открытых узлах. Потребители получают эти пакеты из соответствующих узлов, добавляют их в свои проекты, а затем вызывают функции пакета в коде своего проекта. При этом NuGet сам обрабатывает все промежуточные данные.
Поток пакетов между создателями, узлами и потребителями
Независимо от своей природы, узел выступает в качестве точки подключения между создателями и потребителями пакета. Создатели разрабатывают полезные пакеты NuGet и публикуют их на узле. Потребители ищут полезные и совместимые пакеты на доступных узлах, скачивая эти пакеты и включая их в свои проекты. После установки в проекте API пакеты становятся доступны остальной части кода проекта.
Совместимость пакета с разными целевыми платформами
Кроме поддержки размещения, NuGet также предоставляет широкий набор средств, используемых как создателями, так и потребителями. Сведения о получении конкретных средств см. в разделе Установка клиентских средств NuGet.
Как видите, средства NuGet, с которыми вы работаете, в значительной степени зависят от того, создаете, потребляете или публикуете вы пакеты, а также от используемой платформы. Создатели пакета обычно также являются потребителями, так как берут за основу функции, имеющиеся в других пакетах NuGet. Конечно же, те пакеты, в свою очередь, могут зависеть еще от каких-либо.
Возможность легко брать за основу работу других — это одна из наиболее мощных функций системы управления пакетами. Соответственно, значительная часть работы NuGet заключается в управлении этим деревом или "схемой" зависимостей от имени проекта. Проще говоря, вам нужно заботиться только о тех пакетах, которые вы используете непосредственно в проекте. Если эти пакеты используют другие пакеты (которые, в свою очередь, также используют пакеты), все эти зависимости нижнего уровня обрабатывает NuGet.
На следующем рисунке показан проект, зависящий от пяти пакетов, которые, в свою очередь, зависят от нескольких других.
Обратите внимание, что некоторые пакеты встречаются на графе зависимостей несколько раз. Например, существует три разных потребителя пакета B, и каждый из них может также указывать другую версию этого пакета (не показано). Это обычное дело, особенно для широко используемых пакетов. NuGet выполняет всю работу, чтобы определить, какая именно версия пакета B отвечает потребностям всех потребителей. Затем NuGet делает то же самое для всех других пакетов, независимо от того, насколько глубока схема зависимостей.
Дополнительные сведения о том, как NuGet выполняет эту задачу, см. в разделе Разрешение зависимостей.
Отслеживание ссылок и восстановление пакетов
Так как проекты можно легко перемещать между компьютерами разработчиков, репозиториями управления исходным кодом, серверами сборки и т. д., крайне непрактично хранить двоичные сборки из пакетов NuGet напрямую привязанными к проекту. В этом случае каждая копия проекта будет излишне раздутой (и, следовательно, расходовать пространство в репозиториях системы управления исходным кодом). Кроме того, обновить двоичные файлы пакета до новой версии будет очень сложно, так как обновление будет применяться ко всем копиям проекта.
Вместо этого NuGet поддерживает простой список ссылок на пакеты, от которых зависит проект, включая зависимости верхнего и нижнего уровня. То есть при установке пакета с некоторого узла в проект NuGet записывает идентификатор пакета и номер версии в этот список ссылок. (При удалении пакет, конечно же, убирается из этого списка.) Затем в NuGet можно восстановить все связанные пакеты по запросу, как описано в статье о восстановлении пакета.
С помощью одного только списка ссылок NuGet может переустановить, то есть восстановить, все эти пакеты с открытых и (или) закрытых узлов в любой момент времени. При фиксации проекта в системе управления исходным кодом или предоставления его для общего доступа каким-либо иным образом нужно включить только список ссылок и исключить какие-либо двоичные файлы пакета (см. раздел Пропуск пакетов NuGet в системах управления исходным кодом.)
Компьютер, принимающий проект, например сервер сборки, получающий копию проекта в рамках работы системы автоматического развертывания, просто запрашивает у NuGet восстановление зависимости всякий раз, когда они понадобятся. Системы сборки, такие как Azure DevOps, предоставляют шаги "Восстановление NuGet" именно для этой цели. Аналогично, когда разработчики получают копию проекта (например, при клонировании репозитория), они могут вызвать такие команды, как nuget restore (CLI NuGet), dotnet restore (CLI dotnet) или Install-Package (консоль диспетчера пакетов), чтобы получить все необходимые пакеты. Visual Studio, со своей стороны, автоматически восстанавливает пакеты при создании проекта (при условии, что включено автоматическое восстановление, как описано в статье Восстановление пакетов).
Очевидно, что основная роль NuGet, связанная с разработчиками, заключается в обслуживании этого списка ссылок от имени проекта и предоставлении средств для эффективного восстановления (и обновления) таких указанных в ссылках пакетов. Этот список хранится в одном из двух указанных ниже форматов управления пакетами:
packages.config : (NuGet 1.0+) XML-файл, содержащий неструктурированный список всех зависимостей в проекте, включая зависимости других установленных пакетов. Установленные или восстановленные пакеты хранятся в папке packages .
Применение конкретного формата управления пакетами зависит от типа проекта и доступной версии Visual Studio и NuGet. Чтобы проверить, какой формат используется, просто найдите packages.config в корневом каталоге проекта после установки первого пакета. Если этот файл отсутствует, найдите в файле проекта элемент .
При наличии возможности выбора рекомендуем использовать PackageReference. Файл packages.config используется в устаревших версиях и больше не применяется в активной разработке.
[!Tip] Различные команды интерфейса командной строки nuget.exe , например nuget install , не добавляют автоматически пакет в список ссылок. Этот список обновляется при установке пакета с помощью диспетчера пакетов Visual Studio (пользовательского интерфейса или консоли) и интерфейса командной строки dotnet.exe .
Что еще делает NuGet?
Мы уже выучили следующие характеристики NuGet:
Чтобы обеспечить эффективную работу этих процессов, NuGet осуществляет некоторые оптимизации в фоновом режиме. В частности, NuGet управляет кэшем пакета и папкой глобальных пакетов, что позволяет упростить установку и повторною установку. Кэш позволяет избежать загрузки пакета, который уже установлен на компьютере. Папка глобальных пакетов позволяет в нескольких проектах совместно использовать один установленный пакет, тем самым уменьшая общий размер пакетов NuGet на компьютере. Это очень удобно, когда вы часто восстанавливаете большее количество пакетов, например, как на сервере сборки. Дополнительные сведения об этих механизмах см. в статье Управление папкой установки глобальных пакетов, кэшем и временными папками.
Кроме того, NuGet обслуживает все спецификации, связанные со структурированием пакетов (включая локализацию и отладочные символы) и ссылками на них (включая диапазоны версий и предварительные версии). NuGet также имеет различные API для работы со своими службами программно и предоставляет поддержку разработчикам, которые пишут расширения Visual Studio и шаблоны проектов.
Если изучить содержание этой документации, можно найти все указанные возможности и заметки о выпуске, отсылающие к самому начальному этапу развития NuGet.
Другие видео о NuGet см. на Channel 9 и YouTube.
Комментарии, вклады и проблемы
Мы убедительно просим вас оставлять комментарии и вносить вклад в эту документацию. Просто выберите команды Отзывы и Изменить вверху любой страницы или посетите репозиторий документации и список проблем с документацией на сайте GitHub.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Instructions for using the NuGet Package Manager UI in Visual Studio for working with NuGet packages.
Install and manage packages in Visual Studio using the NuGet Package Manager
The NuGet Package Manager UI in Visual Studio on Windows allows you to easily install, uninstall, and update NuGet packages in projects and solutions. For the experience in Visual Studio for Mac, see Including a NuGet package in your project. The Package Manager UI is not included with Visual Studio Code.
Find and install a package
In Solution Explorer, right-click either References or a project and select Manage NuGet Packages. .
The Browse tab displays packages by popularity from the currently selected source (see package sources). Search for a specific package using the search box on the upper left. Select a package from the list to display its information, which also enables the Install button along with a version-selection drop-down.
Select the desired version from the drop-down and select Install. Visual Studio installs the package and its dependencies into the project. You may be asked to accept license terms. When installation is complete, the added packages appear on the Installed tab. Packages are also listed in the References node of Solution Explorer, indicating that you can refer to them in the project with using statements.
[!Tip] To include prerelease versions in the search, and to make prerelease versions available in the version drop-down, select the Include prerelease option.
Uninstall a package
In Solution Explorer, right-click either References or the desired project, and select Manage NuGet Packages. .
Select the Installed tab.
Select the package to uninstall (using search to filter the list if necessary) and select Uninstall.
Note that the Include prerelease and Package source controls have no effect when uninstalling packages.
Update a package
In Solution Explorer, right-click either References or the desired project, and select Manage NuGet Packages. . (In web site projects, right-click the Bin folder.)
Select the Updates tab to see packages that have available updates from the selected package sources. Select Include prerelease to include prerelease packages in the update list.
Select the package to update, select the desired version from the drop-down on the right, and select Update.
To update multiple packages to their newest versions, select them in the list and select the Update button above the list.
You can also update an individual package from the Installed tab. In this case, the details for the package include a version selector (subject to the Include prerelease option) and an Update button.
Manage packages for the solution
Managing packages for a solution is a convenient means to work with multiple projects simultaneously.
Select the Tools > NuGet Package Manager > Manage NuGet Packages for Solution. menu command, or right-click the solution and select Manage NuGet Packages. :
When managing packages for the solution, the UI lets you select the projects that are affected by the operations:
Developers typically consider it bad practice to use different versions of the same NuGet package across different projects in the same solution. When you choose to manage packages for a solution, the Package Manager UI provides a Consolidate tab on which you can easily see where packages with distinct version numbers are used by different projects in the solution:
In this example, the ClassLibrary1 project is using EntityFramework 6.2.0, whereas ConsoleApp1 is using EntityFramework 6.1.0. To consolidate package versions, do the following:
- Select the projects to update in the project list.
- Select the version to use in all those projects in the Version control, such as EntityFramework 6.2.0.
- Select the Install button.
The Package Manager installs the selected package version into all selected projects, after which the package no longer appears on the Consolidate tab.
To change the source from which Visual Studio obtains packages, select one from the source selector:
To manage package sources:
Select the Settings icon in the Package Manager UI outlined below or use the Tools > Options command and scroll to NuGet Package Manager:
Select the Package Sources node:
To add a source, select +, edit the name, enter the URL or path in the Source control, and select Update. The source now appears in the selector drop-down.
To change a package source, select it, make edits in the Name and Source boxes, and select Update.
To disable a package source, clear the box to the left of the name in the list.
To remove a package source, select it and then select the X button.
Using the up and down arrow buttons does not change the priority order of the package sources. Visual Studio ignores the order of package sources, using the package from whichever source is first to respond to requests. For more information, see Package restore.
[!Tip] If a package source reappears after deleting it, it may be listed in a computer-level or user-level NuGet.Config files. See Common NuGet configurations for the location of these files, then remove the source by editing the files manually or using the nuget sources command.
Package manager Options control
When a package is selected, the Package Manager UI displays a small, expandable Options control below the version selector (shown here both collapsed and expanded). Note that for some project types, only the Show preview window option is provided.
The following sections explain these options.
Show preview window
When selected, a modal window displays which the dependencies of a chosen package before the package is installed:
Install and Update Options
(Not available for all project types.)
Dependency behavior configures how NuGet decides which versions of dependent packages to install:
- Ignore dependencies skips installing any dependencies, which typically breaks the package being installed.
- Lowest [Default] installs the dependency with the minimal version number that meets the requirements of the primary chosen package.
- Highest Patch installs the version with the same major and minor version numbers, but the highest patch number. For example, if version 1.2.2 is specified then the highest version that starts with 1.2 will be installed
- Highest Minor installs the version with the same major version number but the highest minor number and patch number. If version 1.2.2 is specified, then the highest version that starts with 1 will be installed
- Highest installs the highest available version of the package.
File conflict action specifies how NuGet should handle packages that already exist in the project or local machine:
- Prompt instructs NuGet to ask whether to keep or overwrite existing packages.
- Ignore All instructs NuGet to skip overwriting any existing packages.
- Overwrite All instructs NuGet to overwrite any existing packages.
(Not available for all project types.)
Remove dependencies: when selected, removes any dependent packages if they're not referenced elsewhere in the project.
Force uninstall even if there are dependencies on it: when selected, uninstalls a package even if it's still being referenced in the project. This is typically used in combination with Remove dependencies to remove a package and whatever dependencies it installed. Using this option may, however, lead to broken references in the project. In such cases, you may need to reinstall those other packages.
Читайте также: