nugget что это за папка
Что такое NuGet?
Просто о NET | создано: 13.06.2011 | опубликовано: 13.06.2011 | обновлено: 19.12.2021 | просмотров: 42430 | комментариев: 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
Создание пакета NuGet
Пакет NuGet можно создать двумя способами. Мы рекомендуем использовать более новый подход — создавать пакет из проекта в стиле SDK (это файл проекта, содержимое которого начинается с
✔ РЕКОМЕНДУЕТСЯ использовать файл проекта в стиле SDK для создания пакета NuGet.
Зависимости пакетов
Важные метаданные пакета NuGet
Пакет NuGet поддерживает многие свойства метаданных. В следующей таблице собраны основные метаданные, которые должен предоставлять каждый пакет на NuGet.org.
Проект без лицензии по умолчанию получает статус монопольного авторского права, то есть не может законно использоваться другими пользователями.
✔ РЕКОМЕНДУЕТСЯ выбрать имя пакета NuGet с префиксом, который соответствует критериям для резервирования префикса NuGet.
✔️ СЛЕДУЕТ использовать атрибут href для определения HTTPS-ссылки, указывающей на значок пакета.
NuGet.org и другие аналогичные сайты работают с поддержкой HTTPS, поэтому при отображении изображения с другим протоколом появится предупреждение о смешанном типе содержимого.
✔️ СЛЕДУЕТ использовать для значка пакета изображение размером 64 × 64 с прозрачным фоном, чтобы обеспечить оптимальную видимость.
✔ РЕКОМЕНДУЕТСЯ настроить Source Link, чтобы добавить метаданные системы управления версиями в сборки и пакет NuGet.
Source Link автоматически добавляет метаданные RepositoryUrl и RepositoryType в пакет NuGet. Source Link также добавляет сведения о точном исходном коде, из которого создан пакет. Например, к пакету, созданному из репозитория Git, будет добавлен хэш фиксации в качестве метаданных.
Пакеты предварительного выпуска
Пакеты NuGet с суффиксом версии получают статус предварительной версии. По умолчанию в пользовательском интерфейсе диспетчера пакетов NuGet отображаются только стабильные выпуски, если пользователь не согласился использовать пакеты предварительной версии. Благодаря такой политике пакеты предварительной версии предоставляются для тестирования ограниченному числу пользователей.
В пакетах стабильных выпусков нельзя указывать зависимости от пакетов предварительной версии. В таком случае переведите используемый пакет в режим предварительной версии или укажите зависимость от более ранней стабильной версии.
✔️ СЛЕДУЕТ опубликовать пакет в режиме предварительной версии для тестирования, предварительного просмотра или экспериментов.
✔️ СЛЕДУЕТ опубликовать стабильный выпуск пакета, когда он будет полностью готов, чтобы другие стабильные пакеты могли содержать ссылки на него.
Пакеты символов
NuGet.org размещает свой собственный репозиторий сервера символов. Разработчики могут использовать символы, опубликованные на сервере символов NuGet.org, добавив https://symbols.nuget.org/download/symbols в источники символов в Visual Studio.
Сервер символов NuGet.org поддерживает только новые файлы переносимых символов ( *.pdb ), созданные проектами в стиле пакетов SDK.
Альтернатива созданию пакета символов — внедрение файлов символов в главный пакет NuGet. Главный пакет NuGet будет больше, но внедренные файлы символов позволяют разработчикам не настраивать сервер символов NuGet.org. Если вы создаете пакет NuGet из проекта в стиле SDK, файлы символов в него можно внедрить с помощью свойства AllowedOutputExtensionsInPackageBuildOutputFolder :
✔️ РЕКОМЕНДУЕТСЯ опубликовать символы в виде пакета символов ( *.snupkg ) на веб-сайте NuGet.org.
Благодаря пакетам символов ( *.snupkg ) разработчики получают эффективную среду отладки по требованию, причем при этом не увеличивается размер основного пакета и не снижается производительность восстановления в тех случаях, когда отладка пакета NuGet не предполагается.
Краткое руководство. Установка и использование пакета в Visual Studio (только в Windows)
Предварительные требования
Вы можете установить бесплатный выпуск Community 2019 с сайта visualstudio.com либо использовать выпуск Professional или Enterprise.
Создание проекта
В этом пошаговом руководстве описано, как использовать простое приложение WPF. Создайте проект в Visual Studio, щелкнув Файл Создать проект и введя .NET в поле поиска. Затем выберите Приложение WPF (.NET Framework). Нажмите кнопку Далее. При появлении запроса примите значения по умолчанию для платформы.
Visual Studio создаст проект и откроет его в обозревателе решений.
Добавление пакета NuGet Newtonsoft.Json
Для установки пакета можно использовать диспетчер пакетов NuGet или консоль диспетчера пакетов. При установке пакета NuGet регистрирует зависимость в файле проекта или файле packages.config (в зависимости от формата проекта). Дополнительные сведения см. в разделе Обзор использования пакетов и рабочий процесс.
Диспетчер пакетов NuGet
В обозревателе решений щелкните правой кнопкой мыши узел Ссылки и выберите пункт Управление пакетами NuGet.
Выберите nuget.org в качестве источника пакетов, перейдите на вкладку Обзор, выполните поиск по запросу Newtonsoft.Json, выберите этот пакет в списке и нажмите кнопку Установить.
См. подробнее о диспетчере пакетов NuGet в руководстве по установке пакетов и управлении ими с помощью Visual Studio.
Примите все запросы касательно лицензии.
(Только в Visual Studio 2017.) Если вам будет предложено выбрать формат управления пакетом, выберите PackageReference в файле проекта.
В запросе на проверку изменений нажмите кнопку ОК.
Консоль диспетчера пакетов
Последовательно выберите Сервис Диспетчер пакетов NuGet Консоль диспетчера пакетов.
После открытия консоли убедитесь, что в раскрывающемся списке Проект по умолчанию показан проект, в который требуется установить пакет. Если в решении всего лишь один проект, он автоматически выбран.
Введите команду Install-Package Newtonsoft.Json (см. сведения о ней в Install-Package Newtonsoft.Json ). В окне консоли отображаются выходные данные команды. Ошибки обычно означают, что пакет не совместим с целевой платформой проекта.
Использование интерфейса API Newtonsoft.Json в приложении
Добавив пакет Newtonsoft.Json в проект, вы можете вызывать его метод JsonConvert.SerializeObject для преобразования объекта в удобную для восприятия строку.
Откройте файл MainWindow.xaml и замените существующий элемент Grid следующим кодом:
Откройте файл MainWindow.xaml.cs (который находится в обозревателе решений в узле MainWindow.xaml ) и вставьте в класс MainWindow следующий код.
Несмотря на то что вы добавили пакет Newtonsoft.Json в проект, JsonConvert подчеркивается красной волнистой линией, так как оператор using требуется в верхней части файла кода.
Выполните сборку и запустите приложение, нажав клавишу F5 или выбрав команду Отладка Начать отладку.
Нажмите кнопку. Надпись TextBlock заменится текстом в формате JSON:
Связанные видео
Другие видео о NuGet см. на Channel 9 и YouTube.
Дальнейшие действия
Поздравляем! Вы установили пакет NuGet и поработали с ним.
См. подробнее о возможностях NuGet по приведенным ниже ссылкам.
Терминология OneGet, NuGet, Chocolatey, PowerShellGet — разложим по полочкам
В этой статье я хочу помочь разобраться в структуре пакетных менеджеров под Windows. Статья нацелена больше на тех, кто, как и я, пришли из мира Linux, где принято заходить в понимание процессов ниже уровня абстракций.
Уверен, что абстракции вы уже прочитали и без меня:
chocolatey для установки приложений, nuget — для установки зависимостей разработчиком.
Но это мало того грубо, так еще и неправда.
Итак, какие типы пакетов мы знаем из мира Linux? Внимание: не пакетные менеджеры, а именно сами пакеты. Самые распространенные условно делятся на две группы: ОС-зависимые (deb, rpm) или языко-зависимые (как правило, tar-болы). В принципе можно сказать, что первая группа — это приложения (утилиты), а вторые — зависимости (библиотеки). Но иногда это не так: среди пакетов ОС есть библиотеки, а среди языковых пакетов есть пакеты, устанавливающие еще и утилиты (например stdeb в pip или elastalert в npm) — если их устанавливать глобально, то получится как пакет ОС.
Теперь давайте вспомним, какие пакетные менеджеры мы знаем. Для ОС это apt, yum,… Для языковых: pip, gem, npm, cpan, cpm,…
Что для Windows? Тут мы знакомимся с новым NuGet. Есть NuGet-пакет, а есть одноименный nuget.exe — утилита, которая умеет эти пакеты скачивать и разархивировать. Вообще, она умеет много другое, но это за пределами обсуждаемого вопроса.
Какой расклад мы получаем:
Debian: apt(deb) + pip + npm + gem +…
RHEL: yum(rpm) + pip + npm + gem +…
Windows: nuget(nupkg) + pip + npm + gem +…
Обратите внимание, для msi пакетного менеджера так и не создали (это не совсем так, но пока для простоты).
И вот здесь начинается отличие от Linux. В мире Windows появился какой-то талантливый парень, который решил, что он хочет устанавливать все одной командой. И начал писать open-source’ный проект OneGet (его проприетарное название: PackageManager, который является одним из модулей PowerShell версии >=5.0).
OneGet — это абстрактный интерфейс, который умеет разговаривать с каждым пакетным менеджером на его языке. OneGet публикует для нас набор унифицированных команд. Например, команду Install-Package, которая является wrapper’ом каждый раз для разных команд.
Что получается: мы подключаем к OneGet несколько пакетных менеджеров. Например: NuGet, PIP, NPM.
Далее, если мы хотим поставить какой-то питоний пакет, то мы пишем:
OneGet преобразует это в:
А теперь мы хотим поставить пакет NuGet и запускаем:
В этот раз команда вызвала:
Я соврал. На самом деле Install-Package не вызывает эти команды в бэкграунде — пакетные менеджеры более не используются. Выпали из пищевой цепочки. Вместо них установлены специализированные пакетные провайдеры (считайте плагины PowerShell) для управления инородными пакетами. И эти провайдеры занимаются задачей установки вместо привычных нам пакетных менеджеров. А OneGet над ними начальник. За зависимостями следят сами провайдеры.
Здесь очень важный момент. Старые пакетные менеджеры имели каждый свой список репозиториев (Source в терминологии Windows):
OneGet опирается не на них, а на заменивших их провайдеров. А список репозиториев один для всех, но с указанием, кому какой репозиторий принадлежит — по аналогии с внешними ключами БД.
Смотрим сначала список пакетных провайдеров:
А теперь смотрим кому какой репозиторий принадлежит:
Теперь я сделаю паузу и отвлекусь на один из странных пакетных провайдеров — PowerShellGet. Этот провайдер призван устанавливать модули самого PowerShell. Появился он в PowerShell 2 — еще до прихода PackageManager(aka OneGet). Но они друг другу не ровня. PowerShellGet — это один из рядовых пакетных провайдеров, умеющих делать только свой тип пакетов, а не управленец пакетными провайдерами, как OneGet.
И сейчас вы могли заметить следующую тонкость: список репозиториев в PackageManager выполняется командой Get-PackageSource, а не Get-PSRepository.
Дело в том, что работа этого модуля, как я сказал выше, устанавливать модули PowerShell. В комплект установки входит и регистрация новых командлетов, что он и сделал. Этот командлет дает дополнительные поля при регистрации репозитория (например PublishLocation). Этого не видно, если использовать стандартный командлет:
Возможно вы заметили, что есть два провайдера Chocolatey и ChocolateyGet. Первый — самодельная времянка. Второй — официальный провайдер, который недавно только вышел. Ну вы видите по версиям.
Автоматизированное создание NuGet-пакетов
Коль захотел ты сборки передать
И с ними пламенный привет
Нугетом не забудь запаковать
В пакет!
Часто так бывает, что какое-то подмножество проектов начинает использоваться в разных решениях.
Как правило, программисты, разглядев в соседнем проекте что-то полезное, первое время не заморачиваются — создают папку lib (dll, assemblies и т.п.) и складывают туда скомпилированные сборки из оригинального решения. Со временем становится понятно, что это не самый удобный вариант и вот почему:
Изготовление NuGet-пакетов
Процесс изготовления NuGet-пакетов довольно прост. Вся общая теоретическая часть доступна и, в целом, понятна. В пакеты можно упаковывать различный контент, не только скомпилированные сборки, но и отладочные символы, картинки и т.п. ресурсы, и даже исходный код.
В данном описании мы ограничимся наиболее насущным вопросом упаковки скомпилированных сборок.
Подготовка первого NuGet-пакета
Для того, чтобы наладить автоматизированное создание NuGet-пакетов на сервере построения, надо «состряпать» первую версию пакета. Самый простой и понятный способ создания пакета – это использование NuSpec-файла, который описывает, что это будет за пакет. Получить данный NuSpec-файл можно разными способами:
Для примера, один из наших NuSpec-файлов с сокращениями выглядит как-то так:
Вот небольшие пояснения, касающиеся некоторых секций:
Таким образом мы должны получить заветный «первый пакет», или «опытный образец пакета», то есть nupkg-файл, который можно использовать для установки в проекты через NuGet Package Manager или через NuGet.exe.
Выставка готовых пакетов
Итак, у нас есть пакет, который надо как-то доставлять пользователям через какой-нибудь «канал сбыта пакетов». Считаем, что большинство пользователей будут устанавливать пакеты через Visual Studio. Встроенный в неё NuGet Package Manager понимает два варианта размещения пакетов:
Самый простой вариант для распространения пакетов – создать сетевую папку и складывать пакеты туда.
Стоит отметить, что NuGet позволяет работать не только с общей галереей пакетов https://nuget.org, но и создавать собственные галереи, для этого можно развернуть где-то у себя тот же движок, что используется на https://nuget.org. Наша команда предпочитает этот вариант, поскольку в этом случае появляется возможность отслеживания статистики загрузок, управление полномочиями через сайт, в конце концов, это просто красиво.
Установка галереи может потребовать небольших танцев с бубном, как минимум, в вопросе авторизации, но ничего сложного в этом нет. Публикация пакетов происходит точно так же, как и на NuGet.org, важно при обновлении сайта галереи не потерять архив с уже загруженными пакетами – они хранятся в каталоге узла. Настройка NuGet Package Manager для пользователей в этом случае будет выглядеть как-то так:
Если локальный источник пакетов находится где-то рядом с пользователями, например, в одной локальной сети, то рекомендуется закачать в него все пакеты с зависимостями – это сократит время скачивания пакетов для новых пользователей. Найти nupkg-файлы от зависимых пакетов очень легко – они всегда есть в папке packages, в которую устанавливаются эти самые пакеты (обычно в каталоге с sln-файлом). Также в окне настроек источников пакетов важен порядок – студия будет перебирать источники в случае восстановления пакетов в том порядке, который указан в настройках. Следовательно, если ваш пакет доступен только локально, то первым поставьте свой источник, чтобы не было лишних запросов на nuget.org.
Фабрика по производству NuGet-пакетов
После того, как «опытный образец пакета» сделан и «канал сбыта пакетов» налажен, можно приступать к автоматизации сборки пакетов, чтобы по первому же щелчку мышки мы могли получить горячий и самый свежий NuGet-пакет.
Рассмотрим, как это делается в случае с Team Foundation Server 2013/2015. Для других подобных CI-систем процесс будет похожим.
В свойствах Build Definition (XAML) можно указать PowerShell-скрипт, который выполнится в случае успешного выполнения построения. Именно в этом скрипте и будем вызывать наш «упаковщик», передавая в качестве параметра путь до NuSpec-файла.
Есть несколько моментов, которые следует прояснить для себя: где будет лежать сам NuGet.exe и все необходимые ему файлы (как минимум, конфигурационный файл), где будет находиться NuSpec-файл? С одной стороны, можно положиться на то, что на сервере построения будет в определённом месте расположен NuGet.exe, но если серверов построения несколько и их администрированием заниматься нет желания, то проще всего положить NuGet.exe в Source Control и добавить каталог с его расположением в Workspace, с которым будет выполняться построение. Что касается NuSpec, то его удобно держать рядом с sln-файлом и даже включить в Solution Items для быстрого доступа к нему через Solution Explorer.
Если имеется несколько солюшенов и планируется создавать несколько пакетов, то рекомендуется реализовать один общий PowerShell-скрипт, который будет в качестве параметра получать путь до NuSpec-файла.
Ниже представлены выдержки из такого скрипта:
В скрипте выполняются операции по преобразованию относительных путей в абсолютные (можно без труда найти описание доступных переменных, которые означаются CI-системой при запуске скрипта). В некоторых случаях требуется модификация NuSpec-файла в этом скрипте. Например, таким образом можно обработать создание пакетов для различных конфигураций (Any CPU, x86).
На этом, собственно, настройка автоматического механизма создания NuGet-пакетов заканчивается. Запускаем сборку на сервере построения, проверяем, что всё сработало. Для получения отладочной информации, если что-то пошло не так, не забываем писать –Verbose в параметрах скрипта в настройках определения построения. Готовые пакеты заливаем в общий ресурс или галерею и приглашаем первых пользователей.
Тонкости процесса
Кроме возможностей по созданию NuGet-пакетов, скрипт для сервера построения для каждого из пакетов может запускать утилиту генерации автодокументации на основе XML-комментариев в коде. Данная возможность удобна в том плане, что для каждой версии пакета у нас появляется своя версия автодокументации, это удобно, если пользователи применяют разные версии NuGet-пакетов. Для генерации автодокументации у нас применяется Doxygen. Вот раздел скрипта, посвящённый автодокументации:
Можно создавать свои конфигурации, что мы и делаем. К сожалению, чтобы выполнить «тонкую» настройку всех необходимых параметров, придётся открыть csproj-файл и, как минимум, прописать там TargetFrameworkVersion в каждой из секций конфигурации.
Конфигурации в Visual Studio переключаются в основном тулбаре, в определении сборки на сервере можно выбрать одновременно несколько конфигураций, которые будут компилироваться последовательно.
При этом константы должны быть определены в соответствующей секции csproj-файла:
Пример секции files в NuSpec-файле:
Ещё одна проблема, с которой можно часто столкнуться при использовании (даже не при создании) NuGet-пакетов — проблема подключения одного проекта в несколько солюшенов. Дело в том, что в csproj-файле ссылки на сборки проставляются вплоть до конкретных dll, которые по умолчанию восстанавливаются Visual Studio в папку packages рядом с sln-файлом. Отсюда возникает проблема, когда один и тот же проект включён в несколько солюшенов, располагающихся в разных папках. Для решения этой проблемы можно воспользоваться NuGet-пакетом, который включает в себя специальный Target, который переписывает ссылки перед билдом: https://www.nuget.org/packages/NuGetReferenceHintPathRewrite.
Ещё одной особенностью использования NuGet-пакетов является тема восстановление пакетов при сборке. Дело в том, что до некоторых пор Visual Studio не имела встроенных средств восстановления пакетов, поэтому в csproj дописывался специальный Target, который отвечал за восстановление. В современных Visual Studio (2013+) это уже не актуально, следите за чистотой своих csproj-файлов, никаких Target-ов для восстановления NuGet-пакетов больше не требуется.
Результат
Итак, выполнив всё, что описано в предложенной нами инструкции, вы можете получить готовый механизм упаковки пакетов, который работает без участия человека. Наши пакеты собираются именно так. Разве что, сама публикация требует некоторого внимания.