Додавання пакетів до проекту .NET

  • 2 хв.

.NET постачається з багатьма основними бібліотеками, які обробляють все: від керування файлами до HTTP до стискання файлів. Існує також величезна екосистема сторонніх бібліотек. Щоб інсталювати ці бібліотеки та використовувати їх у своїй програмі, можна скористатися nuGet ( диспетчером пакетів .NET).

.NET та її екосистема використовують слово залежності багато. Залежність пакета – це бібліотека сторонніх постачальників. Це фрагмент коду для повторного використання, який виконує щось і який можна додати до програми. Бібліотека сторонніх постачальників – це те, що програми залежить від функціонувати, отже, слово залежності.

Ви можете вважати бібліотеку сторонніх постачальників пакетом, що зберігається у сховищі. Пакет складається з однієї або кількох бібліотек, які можна додати до програми, щоб скористатися її функціями.

Тут ми зосереджуємося на залежностях пакета. Проте проект .NET може мати інші типи залежностей на додачу до залежностей пакета. Зокрема, інфраструктури, аналізатори, посилання на проекти та спільні залежності проекту.

Визначення потреби в пакеті

Як дізнатися, чи потрібен пакет для проекту? Це складне питання, яке включає в себе кілька факторів:

  • Отримання кращогокоду: запитайте себе, чи ви маєте справу з таким завданням, як безпека, наприклад, і намагаєтеся впровадити автентифікацію та авторизацію. Це завдання, яке потрібно отримати правильно для захисту даних і даних клієнтів. Існують стандартні шаблони та бібліотеки, які використовують багато розробників. Ці бібліотеки впроваджують функції, які вам, імовірно, завжди потрібні, а проблеми виправлюються в міру їх виникнення. Замість власних бібліотек слід використовувати такі бібліотеки. Ви, найімовірніше, не напишете код самостійно, тому що існує так багато випадків, які потрібно враховувати.
  • Заощаджуйте час. Можливо, ви можете самостійно створити більшість елементів, наприклад бібліотек компонентів утиліти або інтерфейсу користувача, але потрібен час. Навіть якщо результати порівнюються з доступними, це не дуже зручно використовувати ваш час для реплікації роботи.
  • обслуговування: усі бібліотеки та програми потребують обслуговування рано чи пізно. Обслуговування передбачає додавання нових функцій і виправлення помилок. Чи варто використовувати ваш час або час вашої команди, щоб підтримувати бібліотеку, або краще дозволити команді програмного забезпечення з відкритим кодом впоратися з нею?

Обчислення пакета

Перш ніж інсталювати бібліотеку, можна перевірити залежності, від яких вона залежить. Ці залежності можуть заохочувати вас використовувати пакет або вони можуть вас стримувати. Нижче наведено кілька факторів, які слід враховувати під час вибору залежності для проекту.

  • Розмір: кількість залежностей може створити великий слід. Якщо ви використовуєте обмежену смугу пропускання або маєте інші апаратні обмеження, цей фактор може бути занепокоєний.
  • ліцензування. Потрібно переконатися, що ліцензія, надана для бібліотеки, охоплює цільове використання незалежно від того, чи є це використання комерційним, особистим або академічним.
  • Активне обслуговування: можливо, проблема полягає в тому, що пакет залежить від залежності, яка не підтримується активно. Залежність може бути застарілою або не оновлюватися протягом тривалого часу.

Ви можете дізнатися більше про пакет, перш ніж інсталювати його, перейшовши до https://www.nuget.org/packages/<package name>. Ця URL-адреса переведе вас на докладну сторінку пакета. Виберіть розкривний список залежностей , щоб дізнатися, на які пакети він використовує функцію.

Кількість перелічених залежностей може не сказати всю правду. Якщо ви завантажите пакет, у вас може виникнути залежність пакета, який містить десятки пакетів. Чому це так? Кожен пакет має список залежностей. Щоб забезпечити можливість використання пакета, усі залежності обходяться та завантажуються під час виконання команди dotnet add package <package name>.

Інсталяція пакета

Інсталювати пакети можна кількома способами. У Visual Studio та Visual Studio для Mac є вбудований командний рядок і графічний інтерфейс користувача для диспетчера пакетів. Ви можете вручну додати посилання на пакет до файлу проекту або інсталювати їх за допомогою засобу інтерфейсу командного рядка (CLI), наприклад Paket або .NET Core CLI.

Для цього модуля для інсталяції пакетів використовується вбудований CLI .NET Core. Ви можете додати пакет до проекту .NET, викликавши команду в терміналі. Типова команда інсталяції має такий вигляд: dotnet add package <name of package>. Коли ви запускаєте команду add package, засіб командного рядка підключається до глобального реєстру, отримує пакет і зберігає його в кешованому розташуванні папки, яке можуть використовувати всі проекти.

Після інсталяції та збірки проекту посилання додаються до папок налагодження або випуску. Каталог проектів має приблизно такий вигляд:

-| bin/
---| Debug/
------| net3.1
--------| <files included in the dependency>

Пошук пакета

Окремі розробники можуть використовувати глобальний реєстр на NuGet.org для пошуку та завантаження потрібних їм пакетів для своїх програм. Компанія може мати стратегію для того, які пакети добре використовувати і де їх знайти.

Скріншот NuGet.org зі списком популярних пакетів.

Пакети можуть бути розташовані в багатьох різних місцях. Деякі з цих джерел можуть бути загальнодоступними, а деякі можуть бути обмежені та доступні лише працівникам певної компанії. Ось кілька місць, де можуть проживати пакети:

  • реєстру: прикладом може бути глобальний реєстр, наприклад реєстр NuGet.org. Ви можете розмістити власні реєстри, які можуть бути приватними або загальнодоступними. Такі служби, як GitHub і Azure DevOps, роблять приватні реєстри доступними.
  • Файли: пакет можна інсталювати з локальної папки. Інсталяція з пакета поширена, коли ви намагаєтеся розробити власні бібліотеки .NET і хочете перевірити пакет локально. Або з якоїсь причини не потрібно використовувати реєстр.

схеми, яка ілюструє зв'язок між авторами пакетів, хостами пакетів і споживачами пакетів.

Засіб nuGet registry and dotnet

Коли ви запускаєте dotnet add package <name of dependency>, .NET переходить до глобального реєстру під назвою NuGet.org реєстру, розташованого на https://nuget.org, і шукає код для завантаження. Ви також можете переглянути цю сторінку для пакетів, якщо ви відвідуєте її за допомогою браузера. Кожен пакет має спеціальний веб-сайт, до якого можна перейти.

знімок екрана цільової сторінки пакета NuGet.

На цих сайтах можна дізнатися більше про розташування вихідного коду. Ви також можете знайти такі відомості, як показники завантаження та відомості про обслуговування.

Знімок екрана: інформація та показники в пакеті NuGet.

Команди .NET

Поки що ви дізналися, як інсталювати залежності за допомогою .NET Core CLI. Але цей інструмент може зробити набагато більше.

.NET Core CLI має досить багато команд. Ці команди допомагають виконувати такі завдання, як інсталяція пакетів, пакети створення та ініціалізація проектів .NET. Не потрібно детально знати всі команди. Коли ви починаєте роботу з .NET, ви, швидше за все, використовуватимете лише підмножину команд. Коли ви розширюєте використання .NET, ви можете використовувати більше команд із різних категорій.

Щоб запам'ятати, що виконуються команди, вони можуть вважатися такими, що належать до категорій:

  • Керування залежностями: команди цієї категорії охоплюють інсталяцію, видалення, очищення після інсталяції пакетів і оновлення пакетів.
  • Запуск програм. Засіб .NET Core допоможе керувати потоками в розробці програми. Прикладами потоків програм є запуск тестів, стандартні коди та запуск команд перенесення для оновлення проектів.
  • Створення та публікація пакетів: кілька команд можуть допомогти вам із такими завданнями, як створення стиснутого пакета та надсилання пакета до реєстру.

Якщо потрібно переглянути докладний список усіх команд, введіть dotnet --help у терміналі.

Інсталяція пакета

Скористайтеся командою dotnet add package <dependency name>, щоб інсталювати звичайну залежність, яка має використовуватися як частина програми.

Примітка

Деякі пакети можна інсталювати глобально. Ці пакети не потрібно імпортувати до проекту. Тому багато глобальних пакетів – це інструменти або шаблони CLI. Ці глобальні інструменти також можна інсталювати зі сховища пакетів. Засоби інсталяції за допомогою команди dotnet tool install <name of package>. Інсталюйте шаблони за допомогою команди dotnet new -i <name of package>.

Після інсталяції

Інстальовані пакети наведено в розділі dependencies файлу .csproj. Щоб дізнатися, які пакети розташовано в папці, введіть dotnet list package.

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

У цій команді перелічено лише пакети верхнього рівня, а не залежності тих пакетів, які ми називаємо транзитними пакетами. Ця команда чудово підходить для швидкого вигляду. Якщо потрібно переглянути докладніші відомості, можна перелічити всі транзитні пакети. У такому разі команда list має такий вигляд:

dotnet list package --include-transitive

Включно з транзитними засобами, ви можете бачити залежності разом з усіма інстальованими пакетами. Якщо запустити dotnet list package --include-transitive, ви можете отримати такий результат:

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

   Transitive Package               Resolved
   > Humanizer.Core                 2.7.9
   > Humanizer.Core.af              2.7.9
   > Humanizer.Core.ar              2.7.9
   > Humanizer.Core.bg              2.7.9
   > Humanizer.Core.bn-BD           2.7.9
   > Humanizer.Core.cs              2.7.9
   ...

Відновити залежності

Коли ви створюєте або клонуєте проект, включені залежності не завантажуються та не інсталюються, доки не буде створено проект. Ви можете вручну відновити залежності та засоби, визначені у файлі проекту, виконавши команду dotnet restore. У більшості випадків явно не потрібно використовувати цю команду. Якщо потрібно, функція відновлення NuGet запускається неявно, коли ви запускаєте такі команди, як new, buildта run.

Очищення залежностей

Рано чи пізно ви, швидше за все, зрозумієте, що вам більше не потрібен пакет. Або ви можете усвідомити, що інстальований пакет не той, який вам потрібен. Можливо, ви знайшли ту, яка краще виконує завдання. Незалежно від причини слід видалити залежності, які не використовуються. Це дає змогу очищати речі. Крім того, залежності займають місце.

Щоб видалити пакет із проекту, скористайтеся командою remove, наприклад: dotnet remove package <name of dependency>. Ця команда видаляє пакет із файлу .csproj проекту.