Что такое nuget в visual studio
Разумеется, нет смысла заниматься сразу реализацией реального API, проще проверить всё на маленьком примере. Именно так я и поступил, и хочу пройти путь до работающего решения ещё раз вместе с вами. Краткий список шагов будет приведён в конце статьи.
Первые попытки
Чтобы двинуться дальше, создадим проект нашей тестовой библиотеки. В файле .csproj DryWetMIDI указаны TFM netstandard2.0 и net45, поэтому для тестового проекта я также указал эти целевые платформы для приближения к реальным условиям. Проект назовём DualLibClassLibrary, внутри будет всего один файл Class.cs:
Кроме того, нам, разумеется, нужны сами нативные сборки (test.dll и test.dylib). Я собрал их из простого кода на C (к слову, такого подхода буду придерживаться затем и в реальной библиотеке):
Если интересно, файлы test.dll и test.dylib создавал в рамках тестового пайплайна в Azure DevOps (в действительности двух, для Windows и macOS). В конце концов, мне нужно будет делать всё в рамках CI, так что решил сразу проверить, как всё будет происходить в реальности. Пайплайн простой, состоит из 3 шагов:
1. сгенерировать файл с кодом на C (задача PowerShell):
( return 456; для macOS);
2. собрать библиотеку (задача Command Line):
(test.dylib для macOS);
3. опубликовать артефакт с библиотекой (задача Publish Pipeline Artifacts).
Итак, имеем файлы test.dll и test.dylib, предоставляющие одну и ту же функцию Foo , которая для Windows возвращает 123 , а для macOS – 456 , так что мы всегда сможем проверить корректность вызова и результата. Файлы положим рядом с DualLibClassLibrary.csproj.
Теперь нужно понять, как добавить их в NuGet пакет так, чтобы после установки пакета они копировались в выходную директорию при сборке приложения, обеспечивая таким образом работу установленной библиотеки. Так как библиотека у нас кроссплатформенная и использует новый формат файла .csproj (SDK style), очень хочется там и объявить инструкции для упаковки файлов. Изучив немного вопрос, пришёл к такому содержимому .csproj:
dotnet pack .\DualLibClassLibrary.sln -c Release
Файлы test.dll и test.dylib добавились из пакета
Выглядит обнадёживающе, пишем в файле Program.cs простой код:
Запускаем и грустим:
Программа не нашла файл test.dll
Что ж, заглянем в папку bin/Debug:
Файлы test.dll и test.dylib отсутствуют в выходной директории приложения
И правда нет файлов. Как же так, <CopyToOutputDirectory> мы им указали, в структуре проекта файлы видны. Проверив содержимое .csproj нашего приложения, всё становится понятно:
В csproj полный беспорядок с добавленными файлами
Во-первых, элемент <CopyToOutputDirectory> отсутствует, а во-вторых, по неведомой причине test.dylib добавился как элемент <None> , а test.dll как элемент <Content> . Остаётся только посмотреть содержимое файла .nupkg. Воспользовавшись программой NuGet Package Explorer, видим следующий манифест:
Как видим, файлы добавились без атрибута copyToOutput , что печально (про атрибут можно почитать в таблице тут: Using the contentFiles element for content files).
Копирование файлов в выходную директорию при сборке приложения
Элемент <PackageCopyToOutput> как раз должен привнести атрибут copyToOutput в манифест пакета. Кроме того, явно указал папки, куда нужно положить файлы, дабы избежать директорий вроде any. Подробнее о том, как всё это работает, можно почитать тут: Including content in a package.
Собираем снова наш пакет и проверяем манифест:
Теперь всё выглядит куда лучше, простая структура файлов и атрибут copyToOutput на месте. Устанавливаем библиотеку в наше консольное приложение и запускаем:
copyToOutput ситуацию не спасает
Всё так же файлов нет в выходной директории приложения
Кроме слегка изменённого текста исключения разницы не видно. Отписался в issue по итогу, на что мне ответили:
Please see our docs on contentFiles . It supports adding different content depending on project's target framework and language, and therefore needs files in a specific structure which your package is not currently using.
Есть статья в документации Microsoft с подозрительно нужным заголовком: Creating native packages. Статья не сильно содержательная, однако кое-что полезное из неё можно почерпнуть. А именно, что можно сделать файл .targets, где мы и укажем <CopyToOutputDirectory> нашим файлам. Сам файл .targets мы включим в пакет вместе с нативными библиотеками. Сказано – сделано. Создаём файл DualLibClassLibrary.targets:
А в файле DualLibClassLibrary.csproj пропишем:
Ошибка уже другая
Данная ошибка может возникнуть из-за несоответствующей разрядности приложения и нативных сборок. Я собирал их на 64-битных системах, приложение запускаю также в 64-битной ОС. Что ж, продолжаем наше путешествие.
Поддержка 32- и 64-битных процессов
Если зайти в свойства проекта приложения в Visual Studio на вкладку Build, обнаружим такую опцию:
Процесс будет 32-битным
Можно, конечно, выключить эту опцию, и приложение наконец напечатает верный результат:
Result = 123000. Press any key to exit.
Но, разумеется, это не решение по следующим причинам:
не будет возможности использовать библиотеку в 32-битных процессах;
придётся требовать от пользователей лишних действий в виде отключения галки;
Конечно же, так никуда не годится, и проблему нужно победить. На самом деле, вариант тут очевиден: сделать нативные сборки для каждой операционной системы в двух вариантах – 32- и 64-битном. То есть поставка пакета чуть распухнет, вместо 2 платформозависимых библиотек внутри будут 4. Я в этом ничего плохого не вижу, ибо файлы всё равно небольшие, а потому буду продолжать именно с этим подходом (тем более, что иного не придумал).
Немного расскажу о том, как собирал 32-битные версии библиотек. Как я упоминал выше, я произвожу сборку в конвейерах Azure DevOps через gcc. У gcc есть флаг -m32 , который, по идее, должен как раз собрать 32-битную библиотеку. На сборочных агентах с macOS всё здорово, а вот на Windows получил нелицеприятные логи:
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib\libuser32.a when searching for -luser32
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a when searching for -lmsvcrt
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmsvcrt
collect2.exe: error: ld returned 1 exit status
Задав вопрос и на StackOverflow, и в Microsoft Developer Community, выяснилось, что на агентах Microsoft не предустановлен 32-битный MinGW, что и приводит к падению. Попробовав множество вариантов, я остановился на проекте brechtsanders/winlibs_mingw, придя к простому PowerShell скрипту:
Используя поставляемый в составе архива компилятор i686-w64-mingw32-gcc.exe, удалось наконец-таки собрать 32-битный файл test.dll. Ура!
Теперь осталось придумать, как заставить нашу библиотеку вызывать API либо из 32- либо из 64-битной сборки. Я думаю, варианты тут есть разные, я остановился на таком:
собираем нативные библиотеки test32.dll, test64.dll, test32.dylib и test64.dylib;
делаем абстрактный класс Api с абстрактными методами, соответствующими нашему managed API для внутреннего использования;
делаем два наследника Api32 и Api64 , в которых реализуем абстрактный API из родительского класса, вызывая unmanaged API из test32 и test64 соответственно;
делаем класс ApiProvider , чьё свойство Api будет отдавать нам реализацию, соответствующую разрядности текущего процесса.
Приведу код файлов:
Api.cs
Api32.cs
Api64.cs
ApiProvider.cs
И тогда код нашего класса Class будет таким:
Собрав пакет (разумеется, обновив предварительно содержимое файлов DualLibClassLibrary.targets и DualLibClassLibrary.csproj, добавив новые файлы), убедимся, что метод нашей библиотеки работает корректно при любой разрядности процесса приложения.
Заключение
Я привёл полную хронологию моих мытарств касаемо создания NuGet пакета с платформозависимым API, но будет полезно кратко перечислить основные моменты (я же обещал инструкцию):
создать нативные сборки, причём в двух вариантах: 32- и 64-битном;
положить их рядом с проектом библиотеки (можно и в папку какую-то, главное путь указать к ним потом верный);
добавить файл .targets, в котором для всех нативных сборок добавить элемент <CopyToOutputDirectory> с желаемым значением;
в файле .csproj библиотеки прописать упаковку как нативных сборок, так и файла .targets (должен пойти в папку build пакета);
реализовать механизм выбора нужной версии нативной сборки в зависимости от разрядности процесса.
Это всё. Солюшн нашей тестовой библиотеки можно взять отсюда: DualLibClassLibrary.zip. Решение было проверено в следующих сценариях на Windows и macOS:
Касаемо проверки в 32- и 64-битном процессах – проверял только на Windows, не уверен, как проверить это на macOS.
Ключевой инструмент для любой современной платформы разработки — это механизм, с помощью которого разработчики могут создавать, передавать друг другу и использовать полезный код. Часто такой код распределен по "пакетам", включающим скомпилированный код (в виде библиотек 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>.
При наличии возможности выбора рекомендуем использовать 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.
С помощью пользовательского интерфейса диспетчера пакетов NuGet в Visual Studio вы можете легко устанавливать, удалять и обновлять пакеты NuGet в проектах и решениях в ОС Windows. Если вы используете Visual Studio для Mac, см. руководство по включению пакета NuGet в проект. Пользовательский интерфейс диспетчера пакетов не входит в Visual Studio Code.
Поиск и установка пакета
В обозревателе решений щелкните правой кнопкой мыши Ссылки или сам проект и выберите Управление пакетами NuGet.
На вкладке Обзор по популярности отображаются пакеты из выбранного в данный момент источника (см. подробнее об источниках пакетов). Выполните поиск определенного пакета с помощью поля поиска в левом верхнем углу. Выберите пакет в списке, чтобы отобразить сведения о нем. Это также активирует кнопку Установить и раскрывающийся список для выбора версии.
Выберите нужную версию в раскрывающемся списке и щелкните Установить. Visual Studio установит пакет и его зависимости в проект. Может появиться запрос на принятие условий лицензионного соглашения. После завершения установки добавленные пакеты отобразятся на вкладке Установленные. Пакеты также перечислены в узле Ссылки обозревателя решений. Это значит, что их можно указывать в проекте с помощью инструкций using .
Чтобы включить предварительные версии в поиск и сделать их доступными в раскрывающемся списке версий, щелкните Включить предварительные версии.
Удаление пакета
В обозревателе решений щелкните правой кнопкой мыши Ссылки или сам проект и выберите Управление пакетами NuGet.
Откройте вкладку Установленные.
Выберите пакет для удаления (при необходимости используйте поиск, чтобы отфильтровать список) и щелкните Удалить.
Обратите внимание, что элементы управления Включить предварительные версии и Источник пакета не применяются при удалении пакетов.
Обновление пакета
В обозревателе решений щелкните правой кнопкой мыши Ссылки или сам проект и выберите Управление пакетами NuGet. (В проектах веб-сайтов щелкните правой кнопкой мыши папку Bin.)
Перейдите на вкладку Обновления, чтобы просмотреть пакеты, для которых доступны обновления из выбранных источников пакетов. Выберите Включить предварительные версии, чтобы включить предварительные версии пакетов в список обновлений.
Последовательно выберите пакет для обновления и нужную версию в раскрывающемся списке справа, а затем щелкните Обновить.
Чтобы обновить несколько пакетов до последних версий, выберите их в списке и нажмите кнопку Обновить, расположенную над списком.
Кроме того, можно обновить отдельный пакет на вкладке Установленные. В этом случае сведения о пакете будут содержать средство выбора версии (зависит от параметра Включить предварительные версии) и кнопку Обновить.
Управление пакетами для решения
Управление пакетами для решения — это удобный способ одновременно работать с несколькими проектами.
Выберите команду меню Средства > Диспетчер пакетов NuGet > Управление пакетами NuGet для решения или щелкните правой кнопкой мыши решение и выберите Управление пакетами NuGet.
При управлении пакетами для решения пользовательский интерфейс позволяет выбрать проекты, затрагиваемые операциями.
Вкладка "Консолидация"
Разработчики обычно предпочитают не использовать разные версии одного и того же пакета NuGet в разных проектах в одном решении. Когда вы выбираете управление пакетами для решения, в пользовательском интерфейсе диспетчера пакетов появляется вкладка Консолидация, на которой вы можете отслеживать использование пакетов с разными номерами версий разными проектами в решении.
В этом примере проект ClassLibrary1 использует EntityFramework 6.2.0, а ConsoleApp1 использует EntityFramework 6.1.0. Для консолидации версий пакета сделайте следующее:
Диспетчер пакетов устанавливает выбранную версию пакета во все выбранные проекты. После этого пакет больше не будет отображаться на вкладке Консолидация.
Источники пакетов
Чтобы изменить источник, из которого Visual Studio получает пакеты, выберите его в средстве выбора источника.
Для управления источниками пакетов сделайте следующее:
Щелкните значок Параметры в пользовательском интерфейсе диспетчера пакетов, как показано ниже, или выберите Средства > Параметры и прокрутите до пункта Диспетчер пакетов NuGet.
Выберите узел Источники пакетов.
Чтобы добавить источник, выберите + , измените имя, введите URL-адрес или путь в элементе управления Источник и щелкните Обновить. Источник отобразится в раскрывающемся списке для выбора.
Чтобы изменить источник пакета, выберите его, внесите изменения в поля Имя и Источник и щелкните Обновить.
Чтобы отключить источник пакета, снимите флажок слева от имени в списке.
Чтобы удалить источник пакета, выберите его и нажмите кнопку X.
Использование кнопок со стрелками вверх и вниз не меняет приоритетный порядок источников пакетов. Visual Studio игнорирует порядок источников пакетов, используя пакет из любого источника, первым ответившего на запросы. См. подробнее о восстановлении пакетов.
Если источник пакета появляется после удаления, он может быть указан в файлах NuGet.Config уровня компьютера или уровня пользователя. Чтобы определить расположение этих файлов, см. описание распространенных конфигураций NuGet. Затем удалите источник, отредактировав файлы вручную или с помощью команды nuget sources.
Элемент управления "Параметры" диспетчера пакетов
Если пакет выбран, пользовательский интерфейс диспетчера пакетов отображает небольшой развертываемый элемент управления Параметры под средством выбора версий (показан в свернутом и развернутом виде). Обратите внимание, что для некоторых типов проектов предоставляется только параметр Показать окно предварительного просмотра.
Эти параметры объясняются в следующих разделах.
Показать окно предварительного просмотра
При выборе этого параметра модальное окно отображает зависимости выбранного пакета перед его установкой.
Параметры установки и обновления
(доступно не для всех типов проектов)
Поведение зависимости — указывает способ определения устанавливаемых версий зависимых пакетов в NuGet.
- Игнорировать зависимости — пропускает установку зависимостей, что обычно приводит к прерыванию установки пакета.
- Наименьший [по умолчанию] — устанавливает зависимость с минимальным номером версии, соответствующим требованиям основного выбранного пакета.
- Наибольший номер исправления — устанавливает версию с теми же основными и дополнительными номерами версий, но с самым большим номером исправления. Например, если указана версия 1.2.2, будет установлена самая высокая версия, которая начинается с 1.2.
- Наибольший номер дополнительной версии — устанавливает версию с тем же основным номером версии, но с самым большим номером дополнительной версии и номером исправления. Если указана версия 1.2.2, будет установлена самая высокая версия, которая начинается с 1.
- Наибольший — устанавливает самую высокую доступную версию пакета.
Действие при конфликте файлов — указывает, как в NuGet должны обрабатываться пакеты, которые уже существуют в проекте или на локальном компьютере.
- По приглашению — NuGet спрашивает, следует ли сохранять или перезаписывать существующие пакеты.
- Пропустить все — NuGet пропускает перезапись существующих пакетов.
- Перезаписать все — NuGet перезаписывает существующие пакеты.
Параметры удаления
(доступно не для всех типов проектов)
Удалить зависимости — удаляются все зависимые пакеты, если на них нет ссылок в других местах проекта.
Принудительно удалить, даже если есть зависимости от него — пакет удаляется, даже если на него по-прежнему есть ссылка в проекте. Обычно используется в сочетании с удалением зависимостей для удаления пакета и любых установленных зависимостей. Но использование этого параметра может привести к нарушению ссылок в проекте. В таких случаях может потребоваться переустановить другие пакеты.
Под управлением подразумевается поиск, скачивание, установка, настройка, обновление и удаление файлов сторонних разработчиков у себя в приложении.
Технически NuGet Manager представляет собой расширение для Visual Studio, доступное программисту в процессе работы над своим проектом. Если вы используете «студию» версии 2012 и выше, то NuGet уже заранее предустановлен и готов к работе. В случае версии 2010 его нужно установить вручную. Его можно скачать либо с официального сайта, либо установить напрямую из Visual Studio через менеджер дополнений.
Давайте откроем менеджер. Для этого в Solution Explorer щелкаем правой кнопкой мыши по рабочему проекту и в контекстном меню выбираем пункт «Manage NuGet Packages…»:
NuGet Manager открывается в новой вкладке в текстовом редакторе. Интерфейс у него довольно простой.
Три главные вкладки:
- Browse. Найти и установить нужные нам пакеты из хранилища NuGet
- Installed. Список уже установленных в нашем проекте библиотек
- Updates. Библиотеки в нашем проекте, которые можно обновить до новой версии
Также в интерфейсе менеджера представлены:
- Строка поиска. Мы можем искать нужную нам библиотеку, начав вводить ее название
- Кнопка «Обновить состояние окна»
- Галочка «Включать в выдачу предрелизные версии библиотек», например, какие-то тестовые или экспериментальные
- Выпадающий список Package source. В каком месте менеджер будет искать нужные нам библиотеки
- Кнопка «Настройки менеджера»
- Главная панель с результатами выдачи (слева)
- Панель с описанием того компонента, который мы выбрали (справа)
Попробуем установить какую-нибудь библиотеку к нам в проект, например, 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 – это просто незаменимый инструмент для разработчика на сегодняшний день. Он автоматизирует весь процесс работы с пакетами в проекте, а именно поиск, скачивание, установка, настройка, обновление и удаление файлов.
В видео версии этого урока более подробно и наглядно показана работа с этим инструментом.
Читайте также: