nuget org что это
Что такое NuGet?
Просто о NET | создано: 13.06.2011 | опубликовано: 13.06.2011 | обновлено: 18.12.2021 | просмотров: 42428 | комментариев: 2
В статье показано как установить NuGet и что это такое. Показаны примеры управления пакетами NuGet. Достаточно подробно и с картинками.
Если не установлен NuGet
Что такое NuGet не буду подробно рассказывать, разве что пару строк:
Со страниц официального сайта
“NuGet is a Visual Studio extension that makes it easy to install and update open source libraries and tools in Visual Studio.”
А теперь на русском
“Nuget – это одно из расширение Visual Studio, которое позволяет с легкостью устанавливать, обновлять и удалять библиотеки (сборки), компоненты, инструменты.”
Если у Вас не установлен это замечательное расширения для Visual Studio, давайте установим. Запускаем студию, идем в меню: Tools –> Extention Manager. Откроется окно менеджера, в этом окне в левой части выберим Online Gallery, менеджер покажет список доспуных расширений. По идеи, Вы должны сразу увидеть Nuget Package Manager. Но если Вы не увидели его, напишите в строке поиска этого менеджера слово “nuget” и тогда точно перед Вами будет менеджер.
У меня на картинке NuGet Manager отмечен зеленой галкой, которая говорит, что расширение уже установлено. Если Вы нажмете кнопку Install, у Вас появится такой же зеленый значок.
Как установить пакет (способ 1 “Визуальный”)
Я создал просто консольное приложение (просто для демонстрации). В Solution Explorer правой кнопкой мыши нажимаем на Preferences и в меню выбираем пункт Add Library Package references. Этот пункт меню должен появиться после установки менеджера пакетов NuGet.
В открывшемся окне, также как и в менеджере расширений для Visual Studio, есть список доступных галерей (слева). Хочу напомнить, что можно получать пакеты как с официального сайта (NuGet official package source), так и папки на своем компьютере, так и с NuGet-сервера локальной сети.
Я в поиске написал свой ник и увидел список доступных пакетов, которые я сделал сам:
Допустим, что я хочу в своё консольное приложение добавить несколько классов и наполнить их данными, чтобы поэкспериментировать с LINQ. Я выберу пакет SampleData и нажму Install. После установки пакет отметился зеленой галкой, а в списке сборок проекта появилась сборка SampleData, которая содержит классы и данные для них:
Если запустить приложение, то я увижу
Как установить NuGet-пакет (способ 2 “Для продвинутых”)
Давайте теперь создадим другое приложение, пусть оно тоже будет консольное. Теперь будем устанавливать Implementation a simple IoC, этот пакет я сделал тоже сам и для себя (но можете тоже пользовать на здоровье). После установки Nuget Package Manager в меню Visual Studio появились новые пункты, например, Tools –> Library Package Manager –> Package Manager Console.
Открыв консоль можно писать команды для менеджера:
Обратите внимание, что выпадающее окно Package source позволяет выбрать конкретный источник пакетов или использовать все доступные.
Напишу-ка я команду для установки моего пакета с IoC:
Команда NuGetInstall-Package SimpleIoC
Пакет установлен. У меня в приложении появился файл SimpleIoC.cs, который является реализацией паттерна IoC (Инверсия в управлении). Кстати, в приложении появился еще одни новый файл packages.config, который, как раз, и содержит информацию об установленных пакетах. У меня в приложении он имеет теперь вид:
Ясно всё и понятно, что отображает этот файл.
Использование пакетов
Хочу отметить некоторую специфику в работе с пакетами. Дело в том, что пакеты это нечто иное, как просто файлы подгруженные к Вашему проекту с учетом некоторых параметров. Например, мой файл SimpleIoC.cs появляется в проекте с учетов namespace. Процесс подмены шаблона используется тот же, что использует Visual Studio, при создании нового проекта из шаблона (или файла из шаблона). Про свойства в таких шаблонах можно почитать хранилище знаний.
NuGet “умеет” добавлять и удалять сборки, файлы, папки, но при одном условии. Если папка, файл или сборка не поменяла название (содержание). Раз уж я установил пакет, то я могу его и удалить:
Общие сведения о сайте NuGet.org
Роль сайта NuGet.org в экосистеме NuGet
Как общедоступный центр NuGet.org содержит центральный репозиторий с более 100 000 уникальных пакетов, доступными по адресу nuget.org. NuGet.org — это не единственный центр для размещения пакетов. Благодаря технологии NuGet вы можете хранить пакеты в частном облаке (например, в Azure DevOps), частной сети или даже локальной файловой системе. Если вы хотите использовать другой центр или способ размещения, ознакомьтесь со статьей Размещение своих веб-каналов NuGet.
NuGet.org, как и любой другой центр размещения пакетов NuGet, выступает в качестве точки подключения между создателями и потребителями пакета. Создатели разрабатывают полезные пакеты NuGet и публикуют их. Потребители ищут полезные и совместимые пакеты на доступных узлах, скачивая эти пакеты и включая их в свои проекты. После установки в проекте API пакеты становятся доступны остальной части кода проекта.
Учетные записи
Чтобы публиковать пакеты на сайте NuGet.org, сначала вам необходимо создать индивидуальную (пользовательскую) учетную запись. Она будет использоваться в качестве вашего удостоверения на сайте NuGet.org.
Кроме того, на сайте NuGet.org можно создать учетную запись организации. В учетную запись организации могут входить в качестве членов одна или несколько индивидуальных учетных записей. Эти члены могут управлять набором пакетов, используя для этого единое удостоверение владельца. Ваша индивидуальная учетная запись может являться членом любого количества учетных записей организации.
Пакет может принадлежать учетной записи организации так же, как и индивидуальной учетной записи. Для потребителей пакета нет никаких различий между индивидуальной учетной записью и учетной записью организации. Обе они отображаются как объекты owners для пакета.
Ключи API
Получив пакет NuGet (файл .nupkg) для публикации, вы можете опубликовать его на сайте NuGet.org с помощью средства CLI nuget.exe или dotnet.exe, используя ключ API, полученный на этом сайте.
При публикации пакета значение ключа API указывается в команде CLI.
Префиксы идентификаторов
Чтобы сохранить и защитить собственное удостоверение при публикации пакетов, вы можете зарезервировать префиксы идентификаторов. При установке пакета его потребители получают дополнительную информацию о том, что в идентифицирующих свойствах пакета содержатся соответствующие действительности данные.
Введение в NuGet
Ключевой инструмент для любой современной платформы разработки — это механизм, с помощью которого разработчики могут создавать, передавать друг другу и использовать полезный код. Часто такой код распределен по «пакетам», включающим скомпилированный код (в виде библиотек DLL) и другое содержимое, необходимое использующим эти пакеты проектам.
Так как NuGet поддерживает закрытые узлы наряду с открытым узлом nuget.org, с помощью пакетов NuGet вы можете делиться кодом, используемым в рамках организации или рабочей группы. Пакеты NuGet также являются удобным способом факторизовать свой код для использования только в собственных проектах. Иными словами, пакет 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, связанная с разработчиками, заключается в обслуживании этого списка ссылок от имени проекта и предоставлении средств для эффективного восстановления (и обновления) таких указанных в ссылках пакетов. Этот список хранится в одном из двух указанных ниже форматов управления пакетами:
Применение конкретного формата управления пакетами зависит от типа проекта и доступной версии Visual Studio и NuGet. Чтобы проверить, какой формат используется, просто найдите packages.config в корневом каталоге проекта после установки первого пакета. Если этот файл отсутствует, найдите в файле проекта элемент
При наличии возможности выбора рекомендуем использовать PackageReference. Файл packages.config используется в устаревших версиях и больше не применяется в активной разработке.
Что еще делает NuGet?
Мы уже выучили следующие характеристики NuGet:
Чтобы обеспечить эффективную работу этих процессов, NuGet осуществляет некоторые оптимизации в фоновом режиме. В частности, NuGet управляет кэшем пакета и папкой глобальных пакетов, что позволяет упростить установку и повторною установку. Кэш позволяет избежать загрузки пакета, который уже установлен на компьютере. Папка глобальных пакетов позволяет в нескольких проектах совместно использовать один установленный пакет, тем самым уменьшая общий размер пакетов NuGet на компьютере. Это очень удобно, когда вы часто восстанавливаете большее количество пакетов, например, как на сервере сборки. Дополнительные сведения об этих механизмах см. в статье Управление папкой установки глобальных пакетов, кэшем и временными папками.
В рамках отдельного проекта NuGet управляет общей схемой зависимостей, что включает в себя разрешение нескольких ссылок на различные версии одного пакета. Довольно часто проект зависит от одного или нескольких пакетов, имеющих такие же зависимости. Некоторые из наиболее полезных пакетов служебных программ на сайте nuget.org используются многими другими пакетами. В общей схеме зависимостей вы легко можете иметь десять различных ссылок на разные версии одного пакета. Чтобы избежать переноса нескольких версий этого пакета в само приложение, NuGet определяет, какую отдельную версию могут использовать все потребители. (Дополнительные сведения см. в разделе Принципы разрешения зависимостей пакетов в NuGet.)
кроме того, NuGet поддерживает все спецификации, связанные с структурированием пакетов (включая символы локализации и отладки) и способы их ссылки (включая диапазоны версий и предварительные версии). NuGet также имеет различные API для работы со своими службами программно и предоставляет поддержку разработчикам, которые пишут расширения Visual Studio и шаблоны проектов.
Если изучить содержание этой документации, можно найти все указанные возможности и заметки о выпуске, отсылающие к самому начальному этапу развития NuGet.
Связанные видео
Другие видео о NuGet см. на Channel 9 и YouTube.
Комментарии, вклады и проблемы
Наконец, мы очень много запустили комментарии и вклады в эту документацию: просто выберите команды отзыва и редактирования в верхней части любой страницы или посетите страницу « репозиторий документов » и список проблем с документацией по GitHub.
Надеемся, что вам понравится работать с NuGet.
Рабочий процесс использования пакета
На веб-сайте nuget.org и в закрытых коллекциях пакетов, создаваемых в вашей организации, а также на других ресурсах вы можете найти десятки тысяч полезных пакетов, которые могут быть использованы в ваших приложениях и службах. Рабочий процесс использования пакетов во многом соответствует общему независимо от источника пакета.
NuGet запоминает удостоверение и номер версии каждого установленного пакета, записывая эти данные в файл проекта (при использовании формата PackageReference) или в файл в зависимости от типа проекта и версии NuGet. При использовании NuGet 4.0 и более поздних версий советуем использовать формат PackageReference. Кроме того, это можно настроить в Visual Studio через параметры пользовательского интерфейса диспетчера пакетов. В любом случае вы всегда можете найти соответствующий файл и просмотреть полный список зависимостей для вашего проекта.
Рекомендуется всегда проверять лицензии для каждого пакета, который вы планируете использовать в своем программном обеспечении. На веб-сайте nuget.org в правой части страницы с описанием для каждого пакета представлена ссылка на сведения о лицензии. Если для пакета не заданы условия лицензии, следует обратиться непосредственно к владельцу пакета по ссылке для связи с владельцем на странице пакета. Корпорация Майкрософт не предоставляет вам лицензию на какую-либо интеллектуальную собственность сторонних поставщиков пакетов и не несет ответственность за сведения, предоставляемые третьими лицами.
При установке пакетов NuGet, как правило, проверяет доступность пакета из кэша. Вы можете вручную очистить этот кэш из командной строки, как описывается в статье Управление папкой установки глобальных пакетов, кэшем и временными папками.
NuGet также проверяет совместимость целевых платформ, которые поддерживаются пакетом, с вашим проектом. Если пакет не содержит совместимых сборок, NuGet отображает сообщение об ошибке. См. раздел Устранение ошибок с несовместимостью пакетов.
При добавлении кода проекта в репозиторий исходного кода пакеты NuGet, как правило, не включаются. Если впоследствии планируется клонирование репозитория или получение проекта каким-либо образом с построением агентов в таких системах, как Visual Studio Team Services, перед выполнением построения необходимо восстановить требуемые пакеты:
В некоторых случаях требуется переустановить пакеты, которые уже включены в состав проекта, что также может потребовать переустановку зависимостей. Это легко сделать с помощью команды nuget reinstall или консоли диспетчера пакетов NuGet. Дополнительные сведения см. в разделе Повторная установка и обновление пакетов.
Способы установки пакетов NuGet
Пакеты NuGet можно скачать и установить с использованием любого из представленных в следующей таблице методов.